Re: [PATCH 1/3] arm64: kprobes: Move extable address check into arch_prepare_kprobe()

[James Morse]

Hi!

On 08/01/2019 02:39, Masami Hiramatsu wrote:
> On Thu, 3 Jan 2019 17:05:18 +
> James Morse  wrote:
>> On 17/12/2018 06:40, Masami Hiramatsu wrote:
>>> Move extable address check into arch_prepare_kprobe() from
>>> arch_within_kprobe_blacklist().
>>
>> I'm trying to work out the pattern for what should go in the blacklist, and 
>> what
>> should be rejected by the arch code.
>>
>> It seems address-ranges should be blacklisted as the contents don't matter.
>> easy-example: the idmap text.
> 
> Yes, more precisely, the code smaller than a function (symbol), it must be
> rejected by arch_prepare_kprobe(), since blacklist is poplated based on
> kallsyms.

Ah, okay, so the pattern is the blacklist should only be for whole symbols,
(which explains why its usually based on sections).

I see kprobe_add_ksym_blacklist() would go wrong if you give it something like:
platform_drv_probe+0x50/0xb0, as it will log platform_drv_probe+0x50 as the
start_addr and platform_drv_probe+0x50+0xb0 as the end.

But how does anything from the arch code's blacklist get into the
kprobe_blacklist list?

We don't have an arch_populate_kprobe_blacklist(), so rely on
within_kprobe_blacklist() calling arch_within_kprobe_blacklist() with the
address, as well as walking kprobe_blacklist.

Is this cleanup ahead of a series that does away with
arch_within_kprobe_blacklist() so that debugfs list is always complete?


> As I pointed, the exception_table contains some range of code which inside
> functions, must be smaller than function.
> Since those instructions are expected to cause exception (that is main reason
> why it can not be probed on arm64), I thought such situation was similar to
> the limitation of instruction.
> 
> So I think below will be better.
> 
> Please do not blacklisting instructions on exception_table,
> since those are smaller than one function.
> 

I keep tripping over this because the exception_table lists addresses that are
allowed to fault. Nothing looks at the instruction, and we happily kprobe the
same instruction elsewhere.

(based on my assumptions about where you are going next!,), How about:
| The blacklist is exposed via debugfs as a list of symbols. extable entries are
| smaller, so must be filtered out by arch_prepare_kprobe().

(only we currently have more than one blacklist...)


Thanks,

James

Re: [PATCH v2] dmaengine: imx-sdma: refine to load context only once

[Vinod Koul]

On 08-01-19, 12:00, Robin Gong wrote:
> The context loaded only one time before channel running,but
> currently sdma_config_channel() and dma_prep_* duplicated with
> sdma_load_context(), so refine it to load context only one time
> before channel running and reload after the channel terminated.

Applied, thanks

-- 
~Vinod

Re: [PATCH v2] staging: erofs: Add identifier for function definition arguments

[Gao Xiang]

On 2019/1/8 21:24, Sidong Yang wrote:
> Add identifier for function definition arguments in xattr_iter_handlers,
> this change clears the checkpatch.pl issue and make code more explicit.
> 
> Signed-off-by: Sidong Yang 

personally looks good to me.

Reviewed-by: Gao Xiang 

Thanks,
Gao Xiang

Re: [PATCH 0/2] /proc/stat: Reduce irqs counting performance overhead

[Waiman Long]

On 01/08/2019 11:11 AM, Michal Hocko wrote:
> On Tue 08-01-19 13:04:22, Dave Chinner wrote:
>> On Mon, Jan 07, 2019 at 05:41:39PM -0500, Waiman Long wrote:
>>> On 01/07/2019 05:32 PM, Dave Chinner wrote:
 On Mon, Jan 07, 2019 at 10:12:56AM -0500, Waiman Long wrote:
> As newer systems have more and more IRQs and CPUs available in their
> system, the performance of reading /proc/stat frequently is getting
> worse and worse.
 Because the "roll-your-own" per-cpu counter implementaiton has been
 optimised for low possible addition overhead on the premise that
 summing the counters is rare and isn't a performance issue. This
 patchset is a direct indication that this "summing is rare and can
 be slow" premise is now invalid.

 We have percpu counter infrastructure that trades off a small amount
 of addition overhead for zero-cost reading of the counter value.
 i.e. why not just convert this whole mess to percpu_counters and
 then just use percpu_counter_read_positive()? Then we just don't
 care how often userspace reads the /proc file because there is no
 summing involved at all...

 Cheers,

 Dave.
>>> Yes, percpu_counter_read_positive() is cheap. However, you still need to
>>> pay the price somewhere. In the case of percpu_counter, the update is
>>> more expensive.
>> Ummm, that's exactly what I just said. It's a percpu counter that
>> solves the "sum is expensive and frequent" problem, just like you
>> are encountering here. I do not need basic scalability algorithms
>> explained to me.
>>
>>> I would say the percentage of applications that will hit this problem is
>>> small. But for them, this problem has some significant performance overhead.
>> Well, duh!
>>
>> What I was suggesting is that you change the per-cpu counter
>> implementation to the /generic infrastructure/ that solves this
>> problem, and then determine if the extra update overhead is at all
>> measurable. If you can't measure any difference in update overhead,
>> then slapping complexity on the existing counter to attempt to
>> mitigate the summing overhead is the wrong solution.
>>
>> Indeed, it may be that you need o use a custom batch scaling curve
>> for the generic per-cpu coutner infrastructure to mitigate the
>> update overhead, but the fact is we already have generic
>> infrastructure that solves your problem and so the solution should
>> be "use the generic infrastructure" until it can be proven not to
>> work.
>>
>> i.e. prove the generic infrastructure is not fit for purpose and
>> cannot be improved sufficiently to work for this use case before
>> implementing a complex, one-off snowflake counter implementation...
> Completely agreed! Apart from that I find that conversion to a generic
> infrastructure worth even if that doesn't solve the problem at hands
> completely. If for no other reasons then the sheer code removal as kstat
> is not really used for anything apart from this accounting AFAIR. The
> less ad-hoc code we have the better IMHO.
>
> And to the underlying problem. Some proc files do not scale on large
> machines. Maybe it is time to explain that to application writers that
> if they are collecting data too agressively then it won't scale. We can
> only do this much. Lying about numbers by hiding updates is, well,
> lying and won't solve the underlying problem. 

I would not say it is lying. As I said in the changelog, reading
/proc/stat infrequently will give the right counts. Only when it is read
frequently that the data may not be up-to-date. Using
percpu_counter_sum_positive() as suggested by Dave will guarantee that
the counts will likely be off by a certain amount too. So it is also a
trade-off between accuracy and performance.

Cheers,
Longman

perf trace syscall table generation for powerpc with syscall.tbl

[Arnaldo Carvalho de Melo]

Hi Ravi,

I noticed that in:

  commit ab66dcc76d6ab8fae9d69d149ae38c42605e7fc5
  Author: Firoz Khan 
  Date:   Mon Dec 17 16:10:36 2018 +0530

powerpc: generate uapi header and system call table files

powerpc now generates its syscall tables headers from a syscall.tbl just
like x86 and s390, could you please switch to using it, taking the x86
and s390 scripts as a starting point, then test on your systems
everything works?

Thanks,

- Arnaldo

Re: [PATCH v2 1/2] media: uapi: Add H264 low-level decoder API compound controls.

[ayaka]

On 1/8/19 5:52 PM, Randy 'ayaka' Li wrote:

On Thu, Nov 15, 2018 at 03:56:49PM +0100, Maxime Ripard wrote:

From: Pawel Osciak 

Stateless video codecs will require both the H264 metadata and slices in
order to be able to decode frames.

This introduces the definitions for a new pixel format for H264 slices that
have been parsed, as well as the structures used to pass the metadata from
the userspace to the kernel.

Co-Developed-by: Maxime Ripard 
Signed-off-by: Pawel Osciak 
Signed-off-by: Guenter Roeck 
Signed-off-by: Maxime Ripard 
---
  Documentation/media/uapi/v4l/biblio.rst   |   9 +
  .../media/uapi/v4l/extended-controls.rst  | 364 ++
  .../media/uapi/v4l/pixfmt-compressed.rst  |  20 +
  .../media/uapi/v4l/vidioc-queryctrl.rst   |  30 ++
  .../media/videodev2.h.rst.exceptions  |   5 +
  drivers/media/v4l2-core/v4l2-ctrls.c  |  42 ++
  drivers/media/v4l2-core/v4l2-ioctl.c  |   1 +
  include/media/v4l2-ctrls.h|  10 +
  include/uapi/linux/v4l2-controls.h| 166 
  include/uapi/linux/videodev2.h|  11 +
  10 files changed, 658 insertions(+)
+#define V4L2_H264_DPB_ENTRY_FLAG_VALID 0x01
+#define V4L2_H264_DPB_ENTRY_FLAG_ACTIVE0x02
+#define V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM 0x04
+
+struct v4l2_h264_dpb_entry {
+   __u32 tag;
+   __u16 frame_num;
+   __u16 pic_num;

Although the long term reference would use picture order count
and short term for frame num, but only one of them is used
for a entry of a dpb.

Besides, for a frame picture frame_num = pic_num * 2,
and frame_num = pic_num * 2 + 1 for a filed.


I mistook something before and something Herman told me is wrong, I read 
the book explaining the ITU standard.


The index of a short term reference picture would be frame_num or POC 
and LongTermPicNum for long term.


But stateless hardware decoder usually don't care about whether it is 
long term or short term, as the real dpb updating or management work are 
not done by the the driver or device and decoding job would only use the 
two list(or one list for slice P) for reference pictures. So those flag 
for long term or status can be removed as well.


Stateless decoder would care about just reference index of this picture 
and maybe some extra property for the filed coded below. Keeping a 
property here for the index of a picture is enough.



+   /* Note that field is indicated by v4l2_buffer.field */
+   __s32 top_field_order_cnt;
+   __s32 bottom_field_order_cnt;
+   __u8 flags; /* V4L2_H264_DPB_ENTRY_FLAG_* */
+};
+
+struct v4l2_ctrl_h264_decode_param {
+   __u32 num_slices;
+   __u8 idr_pic_flag;
+   __u8 nal_ref_idc;
+   __s32 top_field_order_cnt;
+   __s32 bottom_field_order_cnt;
+   __u8 ref_pic_list_p0[32];
+   __u8 ref_pic_list_b0[32];
+   __u8 ref_pic_list_b1[32];

I would prefer to keep only two list, list0 and list 1.
Anyway P slice just use the list0 and B would use the both.

+   struct v4l2_h264_dpb_entry dpb[16];
+};
+
  #endif
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 173a94d2cbef..dd028e0bf306 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -643,6 +643,7 @@ struct v4l2_pix_format {
  #define V4L2_PIX_FMT_H264 v4l2_fourcc('H', '2', '6', '4') /* H264 with 
start codes */
  #define V4L2_PIX_FMT_H264_NO_SC v4l2_fourcc('A', 'V', 'C', '1') /* H264 
without start codes */
  #define V4L2_PIX_FMT_H264_MVC v4l2_fourcc('M', '2', '6', '4') /* H264 MVC */
+#define V4L2_PIX_FMT_H264_SLICE v4l2_fourcc('S', '2', '6', '4') /* H264 parsed 
slices */
  #define V4L2_PIX_FMT_H263 v4l2_fourcc('H', '2', '6', '3') /* H263 
 */
  #define V4L2_PIX_FMT_MPEG1v4l2_fourcc('M', 'P', 'G', '1') /* MPEG-1 ES
 */
  #define V4L2_PIX_FMT_MPEG2v4l2_fourcc('M', 'P', 'G', '2') /* MPEG-2 ES
 */
@@ -1631,6 +1632,11 @@ struct v4l2_ext_control {
__u32 __user *p_u32;
struct v4l2_ctrl_mpeg2_slice_params __user 
*p_mpeg2_slice_params;
struct v4l2_ctrl_mpeg2_quantization __user 
*p_mpeg2_quantization;
+   struct v4l2_ctrl_h264_sps __user *p_h264_sps;
+   struct v4l2_ctrl_h264_pps __user *p_h264_pps;
+   struct v4l2_ctrl_h264_scaling_matrix __user *p_h264_scal_mtrx;
+   struct v4l2_ctrl_h264_slice_param __user *p_h264_slice_param;
+   struct v4l2_ctrl_h264_decode_param __user *p_h264_decode_param;
void __user *ptr;
};
  } __attribute__ ((packed));
@@ -1678,6 +1684,11 @@ enum v4l2_ctrl_type {
V4L2_CTRL_TYPE_U32   = 0x0102,
V4L2_CTRL_TYPE_MPEG2_SLICE_PARAMS = 0x0103,
V4L2_CTRL_TYPE_MPEG2_QUANTIZATION = 0x0104,
+   V4L2_CTRL_TYPE_H264_SPS  = 0x0105,
+   V4L2_CTRL_TYPE_H264_PPS  = 0x0106,
+   V4L2_CTRL_TYPE_H264_SCALING_MATRIX = 0x0107,
+   

Re: [PATCH 2/2] dmaengine: mediatek: Add MediaTek Command-Queue DMA controller for MT6765 SoC

[Vinod Koul]

On 08-01-19, 20:19, Shun-Chih.Yu wrote:
> On Fri, 2019-01-04 at 18:08 +0530, Vinod Koul wrote:
> > On 27-12-18, 21:10, shun-chih...@mediatek.com wrote:
> > > From: Shun-Chih Yu 

> > Have you tested this with dmatest, if so can you provide results of the
> > test as well.
> Yes, I tested with dmatest in multi-thread version. 
> The results shown below, and I would attach them in the next revision if 
> needed.
> 
> dmatest: dma0chan0-copy2: summary 5000 tests, 0 failures 3500 iops 28037
> KB/s (0)
> dmatest: dma0chan0-copy4: summary 5000 tests, 0 failures 3494 iops 27612
> KB/s (0)
> dmatest: dma0chan0-copy1: summary 5000 tests, 0 failures 3491 iops 27749
> KB/s (0)
> dmatest: dma0chan0-copy7: summary 5000 tests, 0 failures 3673 iops 29092
> KB/s (0)
> dmatest: dma0chan0-copy6: summary 5000 tests, 0 failures 3763 iops 30237
> KB/s (0)
> dmatest: dma0chan0-copy0: summary 5000 tests, 0 failures 3730 iops 30131
> KB/s (0)
> dmatest: dma0chan0-copy3: summary 5000 tests, 0 failures 3717 iops 29569
> KB/s (0)
> dmatest: dma0chan0-copy5: summary 5000 tests, 0 failures 3699 iops 29302
> KB/s (0)

Having them in cover letter helps :)

> > > Signed-off-by: Shun-Chih Yu 
> > > Reviewed-by: Vinod Koul 
> > 
> > This is _WRONG_ I have never provided such tag, can you explain why this
> > was added without my approval?
> So sorry about this, I misunderstood the usage of reviewed-by tag and I
> would remove this. Thanks for pointing out this mistake.

This tag should be added _only_ when someone replies with
Reviewed-by: ..., same goes for Acked-by and Tested-by: ... etc

> > > +static void mtk_dma_write(struct mtk_cqdma_pchan *pc, u32 reg, u32 val)
> > > +{
> > > + writel_relaxed(val, pc->base + reg);
> > 
> > Why is it relaxed one?
> Most of the operations to the CQDMA hardware could be relaxed, and the 

looks like you missed the rest of sentence

> > > +static enum dma_status mtk_cqdma_tx_status(struct dma_chan *c,
> > > +dma_cookie_t cookie,
> > > +struct dma_tx_state *txstate)
> > > +{
> > > + struct mtk_cqdma_vchan *cvc = to_cqdma_vchan(c);
> > > + struct mtk_cqdma_vdesc *cvd;
> > > + struct virt_dma_desc *vd;
> > > + enum dma_status ret;
> > > + unsigned long flags;
> > > + size_t bytes = 0;
> > > +
> > > + ret = dma_cookie_status(c, cookie, txstate);
> > > + if (ret == DMA_COMPLETE || !txstate)
> > > + return ret;
> > > +
> > > + spin_lock_irqsave(>vc.lock, flags);
> > > + vd = mtk_cqdma_find_active_desc(c, cookie);
> > > + spin_unlock_irqrestore(>vc.lock, flags);
> > > +
> > > + if (vd) {
> > > + cvd = to_cqdma_vdesc(vd);
> > > + bytes = cvd->len;
> > > + }
> > > +
> > > + dma_set_residue(txstate, bytes);
> > 
> > Have you tested this and are able to report residue properly?
> > 
> I tested and thought the residue report properly. But after checking the
> definition of residue in tx_status again, I found that should be always
> return 0 in the driver instead, since there is no state DMA_IN_PROGRESS
> or DMA_PAUSED in the driver. I would fix this in the next revision.

So memcpy is quite fast :D, that's why. This is more helpful in
slave-dma which is relatively slow :)

-- 
~Vinod

Re: [PATCH 3/3] drivers: usb :fsl: Remove USB Errata checking code

[kbuild test robot]

Hi yinbo.zhu,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on usb/usb-testing]
[also build test ERROR on v5.0-rc1 next-20190108]
[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/Ran-Wang/usb-kconfig-remove-dependency-FSL_SOC-for-ehci-fsl-driver/20190108-143252
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/usb/phy/phy-fsl-usb.o: In function `fsl_otg_ioctl':
>> phy-fsl-usb.c:(.text+0x444): undefined reference to `otg_statemachine'
   drivers/usb/phy/phy-fsl-usb.o: In function `fsl_otg_start_srp':
   phy-fsl-usb.c:(.text+0x4c0): undefined reference to `otg_statemachine'
   drivers/usb/phy/phy-fsl-usb.o: In function `fsl_otg_set_host':
   phy-fsl-usb.c:(.text+0x5c0): undefined reference to `otg_statemachine'
   drivers/usb/phy/phy-fsl-usb.o: In function `fsl_otg_start_hnp':
   phy-fsl-usb.c:(.text+0x650): undefined reference to `otg_statemachine'
   drivers/usb/phy/phy-fsl-usb.o: In function `show_fsl_usb2_otg_state':
>> phy-fsl-usb.c:(.text+0x754): undefined reference to `usb_otg_state_string'
   drivers/usb/phy/phy-fsl-usb.o: In function `a_wait_enum':
   phy-fsl-usb.c:(.text+0x1064): undefined reference to `otg_statemachine'
   drivers/usb/phy/phy-fsl-usb.o: In function `fsl_otg_set_peripheral':
>> phy-fsl-usb.c:(.text+0x1648): undefined reference to 
>> `usb_gadget_vbus_disconnect'
   phy-fsl-usb.c:(.text+0x1658): undefined reference to `otg_statemachine'

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


.config.gz
Description: application/gzip

Re: [PATCH 0/2] /proc/stat: Reduce irqs counting performance overhead

[Waiman Long]

On 01/07/2019 09:04 PM, Dave Chinner wrote:
> On Mon, Jan 07, 2019 at 05:41:39PM -0500, Waiman Long wrote:
>> On 01/07/2019 05:32 PM, Dave Chinner wrote:
>>> On Mon, Jan 07, 2019 at 10:12:56AM -0500, Waiman Long wrote:
 As newer systems have more and more IRQs and CPUs available in their
 system, the performance of reading /proc/stat frequently is getting
 worse and worse.
>>> Because the "roll-your-own" per-cpu counter implementaiton has been
>>> optimised for low possible addition overhead on the premise that
>>> summing the counters is rare and isn't a performance issue. This
>>> patchset is a direct indication that this "summing is rare and can
>>> be slow" premise is now invalid.
>>>
>>> We have percpu counter infrastructure that trades off a small amount
>>> of addition overhead for zero-cost reading of the counter value.
>>> i.e. why not just convert this whole mess to percpu_counters and
>>> then just use percpu_counter_read_positive()? Then we just don't
>>> care how often userspace reads the /proc file because there is no
>>> summing involved at all...
>>>
>>> Cheers,
>>>
>>> Dave.
>> Yes, percpu_counter_read_positive() is cheap. However, you still need to
>> pay the price somewhere. In the case of percpu_counter, the update is
>> more expensive.
> Ummm, that's exactly what I just said. It's a percpu counter that
> solves the "sum is expensive and frequent" problem, just like you
> are encountering here. I do not need basic scalability algorithms
> explained to me.

What I am trying to say is that the "sum is expensive and frequent" is
only true of a very small percentage of applications. It is not true for
most of them. I am hesitating to add latency to the interrupt path that
will affect all applications.
 
>> I would say the percentage of applications that will hit this problem is
>> small. But for them, this problem has some significant performance overhead.
> Well, duh!
>
> What I was suggesting is that you change the per-cpu counter
> implementation to the /generic infrastructure/ that solves this
> problem, and then determine if the extra update overhead is at all
> measurable. If you can't measure any difference in update overhead,
> then slapping complexity on the existing counter to attempt to
> mitigate the summing overhead is the wrong solution.
>
> Indeed, it may be that you need o use a custom batch scaling curve
> for the generic per-cpu coutner infrastructure to mitigate the
> update overhead, but the fact is we already have generic
> infrastructure that solves your problem and so the solution should
> be "use the generic infrastructure" until it can be proven not to
> work.
>
> i.e. prove the generic infrastructure is not fit for purpose and
> cannot be improved sufficiently to work for this use case before
> implementing a complex, one-off snowflake counter implementation...

I see your point. I like the deferred summation approach that I am
currently using. If I have to modify the current per-cpu counter
implementation to support that and I probably need to add counter
grouping support to amortize the overhead, that can be a major
undertaking. This is not a high priority item for me at the moment, so I
may have to wait until I have some spare time left.

Thanks,
Longman

[PATCH] IB/srp: Use struct_size() in kzalloc()

[Gustavo A. R. Silva]

One of the more common cases of allocation size calculations is finding the
size of a structure that has a zero-sized array at the end, along with memory
for some number of elements for that array. For example:

struct foo {
int stuff;
void *entry[];
};

instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);

Instead of leaving these open-coded and prone to type mistakes, we can now
use the new struct_size() helper:

instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);

This code was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/infiniband/ulp/srp/ib_srp.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/infiniband/ulp/srp/ib_srp.c 
b/drivers/infiniband/ulp/srp/ib_srp.c
index 31d91538bbf4..0f855294ff3f 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -443,8 +443,7 @@ static struct srp_fr_pool *srp_create_fr_pool(struct 
ib_device *device,
if (pool_size <= 0)
goto err;
ret = -ENOMEM;
-   pool = kzalloc(sizeof(struct srp_fr_pool) +
-  pool_size * sizeof(struct srp_fr_desc), GFP_KERNEL);
+   pool = kzalloc(struct_size(pool, desc, pool_size), GFP_KERNEL);
if (!pool)
goto err;
pool->size = pool_size;
-- 
2.20.1

[PATCH v2 1/4] ARM: dts: s5pv210: aries: Add reserved memory for mfc

[Paweł Chmiel]

THis commit adds memory reservation required by MFC to run.
On S5PV210 both regions needs to be on separate memory banks.
Size of both regions is taken from stock sources.

Signed-off-by: Paweł Chmiel 
---
Changes from v1:
   - Fixed name of nodes to be more generic
---
 arch/arm/boot/dts/s5pv210-aries.dtsi | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/boot/dts/s5pv210-aries.dtsi 
b/arch/arm/boot/dts/s5pv210-aries.dtsi
index 575094ea7024..89525e56cc7c 100644
--- a/arch/arm/boot/dts/s5pv210-aries.dtsi
+++ b/arch/arm/boot/dts/s5pv210-aries.dtsi
@@ -23,6 +23,24 @@
0x5000 0x0800>;
};
 
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   mfc_left: region@4300 {
+   compatible = "shared-dma-pool";
+   no-map;
+   reg = <0x4300 0x200>;
+   };
+
+   mfc_right: region@5100 {
+   compatible = "shared-dma-pool";
+   no-map;
+   reg = <0x5100 0x200>;
+   };
+   };
+
wifi_pwrseq: wifi-pwrseq {
compatible = "mmc-pwrseq-simple";
reset-gpios = < 2 GPIO_ACTIVE_LOW>;
@@ -329,6 +347,10 @@
status = "okay";
 };
 
+ {
+   memory-region = <_left>, <_right>;
+};
+
  {
wlan_bt_en: wlan-bt-en {
samsung,pins = "gpb-5";
-- 
2.17.1

[PATCH v2 4/4] ARM: defconfig: s5pv210: Enable more drivers present on Samsung Aries

[Paweł Chmiel]

This commit enables following drivers:
- i2c support (using s3c2410 driver)
- s5p-jpeg
- s5p-mfc
- exynos drm rotator
- pwm support
- pwm vibrator
- fixed regulator
- syscon poweroff
- Atmel maXTouch touchscreen
- Broadcom BCM4329 bluetooth over uart0
- dma devices (so we can use pl330 dma driver)

Disable DEBUG_LL. It's currently set to uart1, but if we want to use it
on Aries, we would need to switch it to uart2, to get any logs.

Signed-off-by: Paweł Chmiel 
Signed-off-by: Jonathan Bakker 
---
 arch/arm/configs/s5pv210_defconfig | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/arch/arm/configs/s5pv210_defconfig 
b/arch/arm/configs/s5pv210_defconfig
index 0159636d4c0d..951196bdf008 100644
--- a/arch/arm/configs/s5pv210_defconfig
+++ b/arch/arm/configs/s5pv210_defconfig
@@ -27,6 +27,11 @@ CONFIG_IP_PNP=y
 CONFIG_IP_PNP_DHCP=y
 CONFIG_IP_PNP_BOOTP=y
 CONFIG_IP_PNP_RARP=y
+CONFIG_BT=m
+CONFIG_BT_RFCOMM=y
+CONFIG_BT_BNEP=y
+CONFIG_BT_HCIUART=m
+CONFIG_BT_HCIUART_BCM=y
 CONFIG_CFG80211=m
 CONFIG_MAC80211=m
 CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
@@ -44,21 +49,35 @@ CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_GPIO=y
 # CONFIG_INPUT_MOUSE is not set
 CONFIG_INPUT_TOUCHSCREEN=y
+CONFIG_TOUCHSCREEN_ATMEL_MXT=m
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_PWM_VIBRA=m
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_SAMSUNG=y
 CONFIG_SERIAL_SAMSUNG_CONSOLE=y
+CONFIG_SERIAL_DEV_BUS=y
 CONFIG_HW_RANDOM=y
 CONFIG_I2C_GPIO=y
+CONFIG_I2C_S3C2410=y
+CONFIG_POWER_RESET=y
+CONFIG_POWER_RESET_SYSCON_POWEROFF=y
 CONFIG_POWER_SUPPLY=y
 CONFIG_BATTERY_MAX17040=y
 # CONFIG_HWMON is not set
 CONFIG_MFD_MAX8998=y
 CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_REGULATOR_MAX8998=y
+CONFIG_MEDIA_SUPPORT=m
+CONFIG_MEDIA_CAMERA_SUPPORT=y
+CONFIG_V4L_MEM2MEM_DRIVERS=y
+CONFIG_VIDEO_SAMSUNG_S5P_JPEG=m
+CONFIG_VIDEO_SAMSUNG_S5P_MFC=m
 CONFIG_DRM=y
 CONFIG_DRM_EXYNOS=y
 CONFIG_DRM_EXYNOS_FIMD=y
 CONFIG_DRM_EXYNOS_DPI=y
+CONFIG_DRM_EXYNOS_ROTATOR=y
 CONFIG_USB=y
 CONFIG_USB_OTG=y
 CONFIG_USB_EHCI_HCD=y
@@ -72,6 +91,9 @@ CONFIG_MMC_SDHCI_S3C=y
 CONFIG_MMC_SDHCI_S3C_DMA=y
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_MAX8998=m
+CONFIG_DMADEVICES=y
+CONFIG_PWM=y
+CONFIG_PWM_SAMSUNG=y
 CONFIG_PHY_SAMSUNG_USB2=m
 CONFIG_PHY_S5PV210_USB2=y
 CONFIG_EXT2_FS=y
@@ -97,6 +119,3 @@ CONFIG_DEBUG_SPINLOCK=y
 CONFIG_DEBUG_MUTEXES=y
 CONFIG_DEBUG_ATOMIC_SLEEP=y
 CONFIG_DEBUG_USER=y
-CONFIG_DEBUG_LL=y
-CONFIG_DEBUG_S3C_UART1=y
-CONFIG_EARLY_PRINTK=y
-- 
2.17.1

[PATCH v2 3/4] ARM: defconfig: s5pv210: Run make savedefconfig

[Paweł Chmiel]

This is result of running savedefconfig. It's preparation for adding
support for more hw present on Samsung Aries based devices.

Signed-off-by: Paweł Chmiel 
---
 arch/arm/configs/s5pv210_defconfig | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/configs/s5pv210_defconfig 
b/arch/arm/configs/s5pv210_defconfig
index a077597369f1..0159636d4c0d 100644
--- a/arch/arm/configs/s5pv210_defconfig
+++ b/arch/arm/configs/s5pv210_defconfig
@@ -1,24 +1,24 @@
 CONFIG_SYSVIPC=y
 CONFIG_NO_HZ=y
 CONFIG_HIGH_RES_TIMERS=y
+CONFIG_PREEMPT=y
 CONFIG_CGROUPS=y
 CONFIG_SYSFS_DEPRECATED=y
 CONFIG_SYSFS_DEPRECATED_V2=y
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_KALLSYMS_ALL=y
-CONFIG_MODULES=y
-CONFIG_MODULE_UNLOAD=y
-# CONFIG_BLK_DEV_BSG is not set
-CONFIG_PARTITION_ADVANCED=y
-CONFIG_BSD_DISKLABEL=y
-CONFIG_SOLARIS_X86_PARTITION=y
 CONFIG_ARCH_S5PV210=y
 CONFIG_VMSPLIT_2G=y
-CONFIG_PREEMPT=y
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_CMDLINE="root=/dev/ram0 rw ramdisk=8192 initrd=0x2080,8M 
console=ttySAC1,115200 init=/linuxrc"
 CONFIG_VFP=y
 CONFIG_NEON=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_BSD_DISKLABEL=y
+CONFIG_SOLARIS_X86_PARTITION=y
 CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_UNIX=y
@@ -87,6 +87,7 @@ CONFIG_NLS_CODEPAGE_437=y
 CONFIG_NLS_ASCII=y
 CONFIG_NLS_ISO8859_1=y
 CONFIG_NLS_UTF8=y
+CONFIG_CRC_CCITT=y
 CONFIG_DEBUG_INFO=y
 CONFIG_MAGIC_SYSRQ=y
 CONFIG_DEBUG_KERNEL=y
@@ -99,4 +100,3 @@ CONFIG_DEBUG_USER=y
 CONFIG_DEBUG_LL=y
 CONFIG_DEBUG_S3C_UART1=y
 CONFIG_EARLY_PRINTK=y
-CONFIG_CRC_CCITT=y
-- 
2.17.1

[PATCH v2 0/4] ARM: dts: s5pv210: aries: Enable more drivers present on Samsung Aries based devices

[Paweł Chmiel]

This patchset enables more drivers for devices present on
 Samsung Aries based devices.

Changes from v1:
  - Removed already applied patches
  - Fixed name of mfc memory reservation nodes
  - Added separate patch with savedefconfig result
  - Fixed configuration of touchscreen

Jonathan Bakker (1):
  ARM: dts: s5pv210: aries: Support for more devices present on Aries

Paweł Chmiel (3):
  ARM: dts: s5pv210: aries: Add reserved memory for mfc
  ARM: defconfig: s5pv210: Run make savedefconfig
  ARM: defconfig: s5pv210: Enable more drivers present on Samsung Aries

 arch/arm/boot/dts/s5pv210-aries.dtsi | 90 
 arch/arm/configs/s5pv210_defconfig   | 41 +
 2 files changed, 120 insertions(+), 11 deletions(-)

-- 
2.17.1

[PATCH v2 2/4] ARM: dts: s5pv210: aries: Support for more devices present on Aries

[Paweł Chmiel]

From: Jonathan Bakker 

This commit enables following devices present on Aries based phones:
- pwm-vibrator attached to PWM 1
- poweroff support
- Atmel maXTouch touchscreen, connected to i2c2
- Broadcom BCM4329 bluetooth over uart0

Signed-off-by: Jonathan Bakker 
Signed-off-by: Paweł Chmiel 
---
Changes from v1:
   - Touchscreen irq pin should have PULL_NONE, since it's already
 pulled up with 2.8v
   - Touchscreen irq should be edge failing (like in vendor sources)
---
 arch/arm/boot/dts/s5pv210-aries.dtsi | 68 
 1 file changed, 68 insertions(+)

diff --git a/arch/arm/boot/dts/s5pv210-aries.dtsi 
b/arch/arm/boot/dts/s5pv210-aries.dtsi
index 89525e56cc7c..8ff70b856334 100644
--- a/arch/arm/boot/dts/s5pv210-aries.dtsi
+++ b/arch/arm/boot/dts/s5pv210-aries.dtsi
@@ -41,6 +41,13 @@
};
};
 
+   vibrator_pwr: regulator-fixed-0 {
+   compatible = "regulator-fixed";
+   regulator-name = "vibrator-en";
+   enable-active-high;
+   gpio = < 1 GPIO_ACTIVE_HIGH>;
+   };
+
wifi_pwrseq: wifi-pwrseq {
compatible = "mmc-pwrseq-simple";
reset-gpios = < 2 GPIO_ACTIVE_LOW>;
@@ -314,6 +321,22 @@
reg = <0x36>;
};
};
+
+   vibrator: pwm-vibrator {
+   compatible = "pwm-vibrator";
+   pwms = < 1 44642 0>;
+   pwm-names = "enable";
+   vcc-supply = <_pwr>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_out>;
+   };
+
+   poweroff: syscon-poweroff {
+   compatible = "syscon-poweroff";
+   regmap = <_syscon>;
+   offset = <0x681c>; /* PS_HOLD_CONTROL */
+   value = <0x5200>;
+   };
 };
 
  {
@@ -347,6 +370,23 @@
status = "okay";
 };
 
+ {
+   samsung,i2c-sda-delay = <100>;
+   samsung,i2c-max-bus-freq = <40>;
+   samsung,i2c-slave-addr = <0x10>;
+   status = "okay";
+
+   touchscreen@4a {
+   compatible = "atmel,maxtouch";
+   reg = <0x4a>;
+   interrupt-parent = <>;
+   interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_irq>;
+   reset-gpios = < 3 GPIO_ACTIVE_HIGH>;
+   };
+};
+
  {
memory-region = <_left>, <_right>;
 };
@@ -372,6 +412,13 @@
samsung,pin-drv = ;
};
 
+   bt_host_wake: bt-host-wake {
+   samsung,pins = "gph2-5";
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
+   };
+
tf_detect: tf-detect {
samsung,pins = "gph3-4";
samsung,pin-function = ;
@@ -384,6 +431,17 @@
samsung,pin-function = ;
samsung,pin-pud = ;
};
+
+   ts_irq: ts-irq {
+   samsung,pins = "gpj0-5";
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
+   };
+};
+
+ {
+   samsung,pwm-outputs = <1>;
 };
 
  {
@@ -421,6 +479,16 @@
 
  {
status = "okay";
+
+   bluetooth {
+   compatible = "brcm,bcm43438-bt";
+   max-speed = <115200>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_data _fctl _host_wake>;
+   shutdown-gpios = < 3 GPIO_ACTIVE_HIGH>;
+   device-wakeup-gpios = < 4 GPIO_ACTIVE_HIGH>;
+   host-wakeup-gpios = < 5 GPIO_ACTIVE_HIGH>;
+   };
 };
 
  {
-- 
2.17.1

Re: [PATCH 5/6] ARM: dts: s5pv210: aries: Support for more devices present on Aries

[Paweł Chmiel]

Dnia poniedziałek, 31 grudnia 2018 14:35:55 CET Krzysztof Kozlowski pisze:
> On Fri, 28 Dec 2018 at 17:18, Paweł Chmiel
>  wrote:
> >
> > From: Jonathan Bakker 
> >
> > This commit enables following devices present on Aries based phones:
> > - pwm-vibrator attached to PWM 1
> > - poweroff support
> > - Atmel maXTouch touchscreen. It's connected to i2c2
> > - Broadcom BCM4329 bluetooth over uart0
> >
> > Signed-off-by: Jonathan Bakker 
> > Signed-off-by: Paweł Chmiel 
> > ---
> >  arch/arm/boot/dts/s5pv210-aries.dtsi | 68 
> >  1 file changed, 68 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/s5pv210-aries.dtsi 
> > b/arch/arm/boot/dts/s5pv210-aries.dtsi
> > index 35ba009a1a33..b7246f879648 100644
> > --- a/arch/arm/boot/dts/s5pv210-aries.dtsi
> > +++ b/arch/arm/boot/dts/s5pv210-aries.dtsi
> > @@ -41,6 +41,13 @@
> > };
> > };
> >
> > +   vibrator_pwr: regulator-fixed-0 {
> > +   compatible = "regulator-fixed";
> > +   regulator-name = "vibrator-en";
> > +   enable-active-high;
> > +   gpio = < 1 GPIO_ACTIVE_HIGH>;
> > +   };
> > +
> > wifi_pwrseq: wifi-pwrseq {
> > compatible = "mmc-pwrseq-simple";
> > reset-gpios = < 2 GPIO_ACTIVE_LOW>;
> > @@ -314,6 +321,22 @@
> > reg = <0x36>;
> > };
> > };
> > +
> > +   vibrator: pwm-vibrator {
> > +   compatible = "pwm-vibrator";
> > +   pwms = < 1 44642 0>;
> > +   pwm-names = "enable";
> > +   vcc-supply = <_pwr>;
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_out>;
> > +   };
> > +
> > +   poweroff: syscon-poweroff {
> > +   compatible = "syscon-poweroff";
> > +   regmap = <_syscon>;
> > +   offset = <0x681c>; /* PS_HOLD_CONTROL */
> > +   value = <0x5200>;
> > +   };
> >  };
> >
> >   {
> > @@ -347,6 +370,23 @@
> > status = "okay";
> >  };
> >
> > + {
> > +   samsung,i2c-sda-delay = <100>;
> > +   samsung,i2c-max-bus-freq = <40>;
> > +   samsung,i2c-slave-addr = <0x10>;
> > +   status = "okay";
> > +
> > +   touchscreen@4a {
> > +   compatible = "atmel,maxtouch";
> > +   reg = <0x4a>;
> > +   interrupt-parent = <>;
> > +   interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_irq>;
> > +   reset-gpios = < 3 GPIO_ACTIVE_HIGH>;
> > +   };
> > +};
> > +
> >   {
> > memory-region = <_left>, <_right>;
> >  };
> > @@ -372,6 +412,13 @@
> > samsung,pin-drv = ;
> > };
> >
> > +   bt_host_wake: bt-host-wake {
> > +   samsung,pins = "gph2-5";
> > +   samsung,pin-function = ;
> > +   samsung,pin-pud = ;
> > +   samsung,pin-drv = ;
> > +   };
> > +
> > tf_detect: tf-detect {
> > samsung,pins = "gph3-4";
> > samsung,pin-function = ;
> > @@ -384,6 +431,17 @@
> > samsung,pin-function = ;
> > samsung,pin-pud = ;
> > };
> > +
> > +   ts_irq: ts-irq {
> > +   samsung,pins = "gpj0-5";
> > +   samsung,pin-function = ;
> > +   samsung,pin-pud = ;
> 
> It seems there is a difference here between Aries and Fascinate. At
> least in vendor kernel. One disables pull and second pulls down.
> Anyway neither of them pulls it up.
Fixed with all other issues in v2.
Thanks

> 
> Best regards,
> Krzysztof

Re: [PATCH] kernel: release ptraced tasks before zap_pid_ns_processes

[Oleg Nesterov]

Sorry for delay, vacation,

On 01/02, Andrei Vagin wrote:
>
> zap_pid_ns_processes() can stuck on waiting tasks from the dead list. In
> this case, we will have one unkillable process with one or more dead
> children.

Thanks!

> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -664,9 +664,6 @@ static void forget_original_parent(struct task_struct 
> *father,
>  {
>   struct task_struct *p, *t, *reaper;
>  
> - if (unlikely(!list_empty(>ptraced)))
> - exit_ptrace(father, dead);
> -
>   /* Can drop and reacquire tasklist_lock */
>   reaper = find_child_reaper(father);
>   if (list_empty(>children))
> @@ -705,8 +702,18 @@ static void exit_notify(struct task_struct *tsk, int 
> group_dead)
>   LIST_HEAD(dead);
>  
>   write_lock_irq(_lock);
> - forget_original_parent(tsk, );
> + if (unlikely(!list_empty(>ptraced)))
> + exit_ptrace(tsk, );
> + write_unlock_irq(_lock);
> +
> + /* Ptraced tasks have to be released before zap_pid_ns_processes(). */
> + list_for_each_entry_safe(p, n, , ptrace_entry) {
> + list_del_init(>ptrace_entry);
> + release_task(p);
> + }
>  
> + write_lock_irq(_lock);
> + forget_original_parent(tsk, );
>   if (group_dead)
>   kill_orphaned_pgrp(tsk->group_leader, NULL);

How about a different fix below? It avoids additional 
write_lock/unlock(tasklist),
and another list_for_each_entry_safe(dead) loop is called only if it is actually
needed.

Or I missed something?

Oleg.


--- x/kernel/exit.c
+++ x/kernel/exit.c
@@ -558,12 +558,14 @@ static struct task_struct *find_alive_th
return NULL;
 }
 
-static struct task_struct *find_child_reaper(struct task_struct *father)
+static struct task_struct *find_child_reaper(struct task_struct *father,
+   struct list_head *dead)
__releases(_lock)
__acquires(_lock)
 {
struct pid_namespace *pid_ns = task_active_pid_ns(father);
struct task_struct *reaper = pid_ns->child_reaper;
+   struct task_struct *p, *n;
 
if (likely(reaper != father))
return reaper;
@@ -579,6 +581,11 @@ static struct task_struct *find_child_re
panic("Attempted to kill init! exitcode=0x%08x\n",
father->signal->group_exit_code ?: father->exit_code);
}
+
+   list_for_each_entry_safe(p, n, , ptrace_entry) {
+   list_del_init(>ptrace_entry);
+   release_task(p);
+   }
zap_pid_ns_processes(pid_ns);
write_lock_irq(_lock);
 
@@ -668,7 +675,7 @@ static void forget_original_parent(struc
exit_ptrace(father, dead);
 
/* Can drop and reacquire tasklist_lock */
-   reaper = find_child_reaper(father);
+   reaper = find_child_reaper(father, dead);
if (list_empty(>children))
return;
 

[PATCH] uwb: use struct_size() in kzalloc()

[Gustavo A. R. Silva]

One of the more common cases of allocation size calculations is finding the
size of a structure that has a zero-sized array at the end, along with memory
for some number of elements for that array. For example:

struct foo {
int stuff;
void *entry[];
};

instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);

Instead of leaving these open-coded and prone to type mistakes, we can now
use the new struct_size() helper:

instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);

This code was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/uwb/drp-ie.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/uwb/drp-ie.c b/drivers/uwb/drp-ie.c
index 1d2a939cfcf8..ed993e363472 100644
--- a/drivers/uwb/drp-ie.c
+++ b/drivers/uwb/drp-ie.c
@@ -125,9 +125,8 @@ static struct uwb_ie_drp *uwb_drp_ie_alloc(void)
 {
struct uwb_ie_drp *drp_ie;
 
-   drp_ie = kzalloc(sizeof(struct uwb_ie_drp) +
-   UWB_NUM_ZONES * sizeof(struct uwb_drp_alloc),
-   GFP_KERNEL);
+   drp_ie = kzalloc(struct_size(drp_ie, allocs, UWB_NUM_ZONES),
+GFP_KERNEL);
if (drp_ie)
drp_ie->hdr.element_id = UWB_IE_DRP;
return drp_ie;
-- 
2.20.1

Re: [PATCH] wireless: ath: return error code upstream

[Kalle Valo]

Kangjie Lu  writes:

> ath6kl_wmi_cmd_send could fail, so let's return its error code upstream.
>
> Signed-off-by: Kangjie Lu 
> ---
>  drivers/net/wireless/ath/ath6kl/wmi.c | 4 +---

The correct prefix is "ath6kl: " but I can fix that.

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#commit_title_is_wrong

-- 
Kalle Valo

Re: [PATCH v2 12/14] drm/stm: do not reply on drmP.h from drm_gem_cma_helper.h

[Benjamin Gaignard]

Le lun. 7 janv. 2019 à 16:59, Noralf Trønnes  a écrit :
>
>
>
> Den 30.12.2018 18.48, skrev Sam Ravnborg:
> > drmP.h was the only header file in the past and a lot
> > of files rely on that drmP.h defines everything.
> > The goal is to one day to delete drmP.h and
> > as a step towards this it will no longer be included in the
> > headers files in include/drm/
> >
> > To prepare stm/ for this add dependencies that
> > othwewise was pulled in by drmP.h from drm_gem_cma_helper.h
> >
> > Sort the include list when we anyway modify it.
> >
> > Signed-off-by: Sam Ravnborg 
> > Cc: Yannick Fertre 
> > Cc: Philippe Cornu 
> > Cc: Benjamin Gaignard 
> > Cc: Vincent Abriou 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > ---
>
> Acked-by: Noralf Trønnes 

Acked-by: Benjamin Gaignard 

> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] wireless: marvell: add checks for the return value of sysfs_create_group

[Kalle Valo]

Kangjie Lu  writes:

> sysfs_create_group() could fail, so let's check its return values and
> issue error messages if it fails.
>
> Signed-off-by: Kangjie Lu 
> ---
>  drivers/net/wireless/marvell/libertas/mesh.c | 4 

The correct prefix is "libertas: ".

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#commit_title_is_wrong

> --- a/drivers/net/wireless/marvell/libertas/mesh.c
> +++ b/drivers/net/wireless/marvell/libertas/mesh.c
> @@ -797,7 +797,11 @@ static void lbs_persist_config_init(struct net_device 
> *dev)
>  {
>   int ret;
>   ret = sysfs_create_group(&(dev->dev.kobj), _opts_group);
> + if (ret)
> + pr_err("failed to create boot_opts_group.\n");

Please add an empty line here for readability and resend the patch as
v2.

>   ret = sysfs_create_group(&(dev->dev.kobj), _ie_group);
> + if (ret)
> + pr_err("failed to create mesh_ie_group.\n");
>  }
>  
>  static void lbs_persist_config_remove(struct net_device *dev)

-- 
Kalle Valo

Re: [PATCH v8 12/26] arm64: irqflags: Use ICC_PMR_EL1 for interrupt masking

[Dave Martin]

On Tue, Jan 08, 2019 at 03:51:18PM +, Marc Zyngier wrote:
> On 08/01/2019 15:40, Dave Martin wrote:
> > On Tue, Jan 08, 2019 at 02:07:30PM +, Julien Thierry wrote:
> >> Instead disabling interrupts by setting the PSR.I bit, use a priority
> >> higher than the one used for interrupts to mask them via PMR.
> >>
> >> When using PMR to disable interrupts, the value of PMR will be used
> >> instead of PSR.[DAIF] for the irqflags.
> >>
> >> Signed-off-by: Julien Thierry 
> >> Suggested-by: Daniel Thompson 
> >> Cc: Catalin Marinas 
> >> Cc: Will Deacon 
> >> Cc: Ard Biesheuvel 
> >> Cc: Oleg Nesterov 
> >> ---
> >>  arch/arm64/include/asm/efi.h  |  11 
> >>  arch/arm64/include/asm/irqflags.h | 123 
> >> +-
> >>  2 files changed, 106 insertions(+), 28 deletions(-)
> > 
> > [...]
> > 
> >> diff --git a/arch/arm64/include/asm/irqflags.h 
> >> b/arch/arm64/include/asm/irqflags.h
> >> index 24692ed..fa3b06f 100644
> >> --- a/arch/arm64/include/asm/irqflags.h
> >> +++ b/arch/arm64/include/asm/irqflags.h
> >> @@ -18,7 +18,9 @@
> > 
> > [...]
> > 
> >>  static inline void arch_local_irq_enable(void)
> >>  {
> >> -  asm volatile(
> >> -  "msrdaifclr, #2 // arch_local_irq_enable"
> >> -  :
> >> +  unsigned long unmasked = GIC_PRIO_IRQON;
> >> +
> >> +  asm volatile(ALTERNATIVE(
> >> +  "msrdaifclr, #2 // arch_local_irq_enable\n"
> >> +  "nop",
> >> +  "msr_s  " __stringify(SYS_ICC_PMR_EL1) ",%0\n"
> >> +  "dsbsy",
> > 
> > I'm still not convinced these dsbs are needed.
> > 
> > Without the dsb, we are probably not guaranteed to take a pending
> > interrupt _immediately_ on unmasking, but I'm not sure that's a
> > problem.
> > 
> > What goes wrong if we omit them?
> 
> Then the GIC doesn't know it can now deliver interrupts of a lower
> priority. Only a dsb can guarantee that the GIC's view of PMR will get
> updated.
> 
> See 9.1.6 (Observability of the effects of accesses to the GIC
> registers), which states:
> 
> 
> Architectural execution of a DSB instruction guarantees that
> — The last value written to ICC_PMR_EL1 or GICC_PMR is observed by the
> associated Redistributor.
> 
> 
> So yes, DSB is required.

But it says neither what is means for the PMR write to be "observed by
the redistributor", nor whether the DSB is required for the
redistributor to observe the write at all.  (So, is an implementation
allowed to cached in the CPU interface indefinitely until forcibly
flushed to the redistributor by a DSB, and in any case can the write's
reaching the distributor in finite time or not have any effect that we
care about in this case?).


My reason for querying this is that temporary local masking of classes
of interrupts seems an obvious use case for the PMR, and the DSB
requirement flies rather in the face of this.


Have we seen hardware where interrupts may stall forever upstream of the
CPU interface after a PMR write, until a dsb is executed by the CPU?

If so that is sad, but I guess we have to live with it.

Also, is it ever important in Linux that a pending interrupt be taken
immediately upon unmasking (and how do we know that said interrupt is
pending)?  If not, we don't care precisely when such interrupts are
pended to the PE, just that such an interrupt cannot be taken before
the PMR write that unmasks it.  It would be insane for the self-
synchronization of PMR writes to lack this guarantee (and a DSB after
the PMR write would do no good anyway in that case).

Happy to be put right -- I'm doubtless showing my ignorance here!

Cheers
---Dave

Re: [PATCH 20/20] cw1200: drop useless LIST_HEAD

[Julia Lawall]

On Tue, 8 Jan 2019, Kalle Valo wrote:

> Julia Lawall  writes:
>
> > Drop LIST_HEAD where the variable it declares has never
> > been used.
> >
> > The semantic patch that fixes this problem is as follows:
> > (http://coccinelle.lip6.fr/)
> >
> > // 
> > @@
> > identifier x;
> > @@
> > - LIST_HEAD(x);
> >   ... when != x
> > // 
> >
> > Fixes: a910e4a94f692 ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN 
> > chipsets")
> > Signed-off-by: Julia Lawall 
> >
> > ---
> > Successfully 0-day tested on 151 configurations.
>
> I assume I can take this to wireless-drivers-next. If you are planning
> to push this via some other tree please let me know.

Please take it.  Thanks.

julia

Re: [PATCH] net: brcm80211: add a check for the status of usb_register

[Kalle Valo]

Kangjie Lu  writes:

> usb_register() may fail, so let's check its status and issue an error
> message if it fails.
>
> Signed-off-by: Kangjie Lu 
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 6 +-

The title prefix should be "brcmfmac: " but I can fix that.

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#commit_title_is_wrong

-- 
Kalle Valo

Re: Regression in v5.0-rc1 with autosuspend hrtimers

[Vincent Guittot]

On Tue, 8 Jan 2019 at 16:53, Tony Lindgren  wrote:
>
> * Vincent Guittot  [190108 08:00]:
> > Hi Tony,
> >
> > On Tue, 8 Jan 2019 at 00:38, Tony Lindgren  wrote:
> > >
> > > Hi all,
> > >
> > > Looks like commit 8234f6734c5d ("PM-runtime: Switch autosuspend
> > > over to using hrtimers") caused a regression on at least
> > > omap5-uevm where 8250 UART rx wake no longer works. I have not
> > > noticed this happening on others so far.
> > >
> > > The devices I've tested all are using 8250 with dedicated
> > > wakeirqs configured for the rx pin. I can see the interrupt
> > > increase on omap5-uevm after some one or more keypresses,
> > > but then nothing. It seems that the uart just falls back
> > > asleep right away or something.
> > >
> > > Any ideas what might be going wrong?
> >
> > What is the autosuspend value ? Can it be that the autosuspend is set
> > to a short value but was finally greater than 10-20ms on arm32. And
> > now the autosuspend happens before and this has changed the sequence ?
>
> It's set to 3 seconds. The difference between let's say
> C-A9 pandaboard (that is working) compared to C-A15 omap5-uevm
> is that the C-A15 has arch_timer in use. Other than that things
> should behave more or less the same way.
>
> Hmm so could it be that we now rely on timers that that may
> not be capable of waking up the system from idle states with
> hrtimer?

With nohz and hrtimer enabled,  timer relies on hrtimer to generate
the tick so you should use the same interrupt.

>
> Regards,
>
> Tony
>

[PATCH] vfio/type1: Fix unmap overflow off-by-one

[Alex Williamson]

The below referenced commit adds a test for integer overflow, but in
doing so prevents the unmap ioctl from ever including the last page of
the address space.  Subtract one to compare to the last address of the
unmap to avoid the overflow and wrap-around.

Fixes: 71a7d3d78e3c ("vfio/type1: silence integer overflow warning")
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1662291
Cc: Dan Carpenter 
Reported-by: Pei Zhang 
Debugged-by: Peter Xu 
Signed-off-by: Alex Williamson 
---
 drivers/vfio/vfio_iommu_type1.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 7651cfb14836..73652e21efec 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -878,7 +878,7 @@ static int vfio_dma_do_unmap(struct vfio_iommu *iommu,
return -EINVAL;
if (!unmap->size || unmap->size & mask)
return -EINVAL;
-   if (unmap->iova + unmap->size < unmap->iova ||
+   if (unmap->iova + unmap->size - 1 < unmap->iova ||
unmap->size > SIZE_MAX)
return -EINVAL;
 

Re: [PATCH v4 10/13] x86: perf/core: use PERF_PMU_CAP_NO_EXCLUDE for exclude incapable PMUs

[Boris Ostrovsky]

On 1/8/19 5:48 AM, Peter Zijlstra wrote:
> On Mon, Jan 07, 2019 at 04:27:27PM +, Andrew Murray wrote:
>> For drivers that do not support context exclusion let's advertise the
>> PERF_PMU_CAP_NOEXCLUDE capability. This ensures that perf will
>> prevent us from handling events where any exclusion flags are set.
>> Let's also remove the now unnecessary check for exclusion flags.
>>
>> Signed-off-by: Andrew Murray 
>> ---
>>  arch/x86/events/amd/ibs.c  | 13 +
>>  arch/x86/events/amd/power.c| 10 ++
>>  arch/x86/events/intel/cstate.c | 12 +++-
>>  arch/x86/events/intel/rapl.c   |  9 ++---
>>  arch/x86/events/intel/uncore_snb.c |  9 ++---
>>  arch/x86/events/msr.c  | 10 ++
>>  6 files changed, 12 insertions(+), 51 deletions(-)
> You (correctly) don't add CAP_NO_EXCLUDE to the main x86 pmu code, but
> then you also don't check if it handles all the various exclude options
> correctly/consistently.
>
> Now; I must admit that that is a bit of a maze, but I think we can at
> least add exclude_idle and exclude_hv fails in there, nothing uses those
> afaict.
>
> On the various exclude options; they are as follows (IIUC):
>
>   - exclude_guest: we're a HV/host-kernel and we don't want the counter
>to run when we run a guest context.
>
>   - exclude_host: we're a HV/host-kernel and we don't want the counter
>   to run when we run in host context.
>
>   - exclude_hv: we're a guest and don't want the counter to run in HV
> context.
>
> Now, KVM always implies exclude_hv afaict (for guests), I'm not sure
> what, if anything Xen does on x86 (IIRC Brendan Gregg once said perf
> works on Xen) -- nor quite sure who to ask, Boris, Jeurgen?

perf does work inside guests.

VPMU is managed by the Xen and it presents to the guest only samples
that are associated with the guest. So from that perspective exclude_hv
doesn't seem to be needed.

There is a VPMU mode that allows profiling whole system (host and
guests) from dom0, and this where exclude_hv might be useful. But this
mode, ahem, needs some work.


-boris

[PATCH v5 3/7] phy: add A3700 COMPHY support

[Miquel Raynal]

Add a driver to support COMPHY, a hardware block providing shared
serdes PHYs on Marvell Armada 3700. This driver uses SMC calls and
rely on having an up-to-date firmware.

SATA, PCie and USB3 host mode have been tested successfully with an
ESPRESSObin. (HS)SGMII mode cannot be tested with this platform.

Evan worked on the original driver structure and Grzegorz on the SMC
calls rework. The structure of this driver has been copied from
Antoine Tenart work on CP110 COMPHY driver.

Signed-off-by: Miquel Raynal 
Co-developed-by: Evan Wang 
Signed-off-by: Evan Wang 
Co-developed-by: Grzegorz Jaszczyk 
Signed-off-by: Grzegorz Jaszczyk 
---
 drivers/phy/marvell/Kconfig  |  12 +
 drivers/phy/marvell/Makefile |   1 +
 drivers/phy/marvell/phy-mvebu-a3700-comphy.c | 318 +++
 3 files changed, 331 insertions(+)
 create mode 100644 drivers/phy/marvell/phy-mvebu-a3700-comphy.c

diff --git a/drivers/phy/marvell/Kconfig b/drivers/phy/marvell/Kconfig
index 6fb4b56e4c14..9c90c0408ea3 100644
--- a/drivers/phy/marvell/Kconfig
+++ b/drivers/phy/marvell/Kconfig
@@ -21,6 +21,18 @@ config PHY_BERLIN_USB
help
  Enable this to support the USB PHY on Marvell Berlin SoCs.
 
+config PHY_MVEBU_A3700_COMPHY
+   tristate "Marvell A3700 comphy driver"
+   depends on ARCH_MVEBU || COMPILE_TEST
+   depends on OF
+   depends on HAVE_ARM_SMCCC
+   default y
+   select GENERIC_PHY
+   help
+ This driver allows to control the comphy, a hardware block providing
+ shared serdes PHYs on Marvell Armada 3700. Its serdes lanes can be
+ used by various controllers: Ethernet, SATA, USB3, PCIe.
+
 config PHY_MVEBU_CP110_COMPHY
tristate "Marvell CP110 comphy driver"
depends on ARCH_MVEBU || COMPILE_TEST
diff --git a/drivers/phy/marvell/Makefile b/drivers/phy/marvell/Makefile
index 3975b144f8ec..c13a0c8ab6f0 100644
--- a/drivers/phy/marvell/Makefile
+++ b/drivers/phy/marvell/Makefile
@@ -2,6 +2,7 @@
 obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
 obj-$(CONFIG_PHY_BERLIN_SATA)  += phy-berlin-sata.o
 obj-$(CONFIG_PHY_BERLIN_USB)   += phy-berlin-usb.o
+obj-$(CONFIG_PHY_MVEBU_A3700_COMPHY)   += phy-mvebu-a3700-comphy.o
 obj-$(CONFIG_PHY_MVEBU_CP110_COMPHY)   += phy-mvebu-cp110-comphy.o
 obj-$(CONFIG_PHY_MVEBU_SATA)   += phy-mvebu-sata.o
 obj-$(CONFIG_PHY_PXA_28NM_HSIC)+= phy-pxa-28nm-hsic.o
diff --git a/drivers/phy/marvell/phy-mvebu-a3700-comphy.c 
b/drivers/phy/marvell/phy-mvebu-a3700-comphy.c
new file mode 100644
index ..8812a104c233
--- /dev/null
+++ b/drivers/phy/marvell/phy-mvebu-a3700-comphy.c
@@ -0,0 +1,318 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Marvell
+ *
+ * Authors:
+ *   Evan Wang 
+ *   Miquèl Raynal 
+ *
+ * Structure inspired from phy-mvebu-cp110-comphy.c written by Antoine Tenart.
+ * SMC call initial support done by Grzegorz Jaszczyk.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MVEBU_A3700_COMPHY_LANES   3
+#define MVEBU_A3700_COMPHY_PORTS   2
+
+/* COMPHY Fast SMC function identifiers */
+#define COMPHY_SIP_POWER_ON0x8201
+#define COMPHY_SIP_POWER_OFF   0x8202
+#define COMPHY_SIP_PLL_LOCK0x8203
+
+#define COMPHY_FW_MODE_SATA0x1
+#define COMPHY_FW_MODE_SGMII   0x2
+#define COMPHY_FW_MODE_HS_SGMII0x3
+#define COMPHY_FW_MODE_USB3H   0x4
+#define COMPHY_FW_MODE_USB3D   0x5
+#define COMPHY_FW_MODE_PCIE0x6
+#define COMPHY_FW_MODE_RXAUI   0x7
+#define COMPHY_FW_MODE_XFI 0x8
+#define COMPHY_FW_MODE_SFI 0x9
+#define COMPHY_FW_MODE_USB30xa
+
+#define COMPHY_FW_SPEED_1_25G  0 /* SGMII 1G */
+#define COMPHY_FW_SPEED_2_5G   1
+#define COMPHY_FW_SPEED_3_125G 2 /* SGMII 2.5G */
+#define COMPHY_FW_SPEED_5G 3
+#define COMPHY_FW_SPEED_5_15625G   4 /* XFI 5G */
+#define COMPHY_FW_SPEED_6G 5
+#define COMPHY_FW_SPEED_10_3125G   6 /* XFI 10G */
+#define COMPHY_FW_SPEED_MAX0x3F
+
+#define COMPHY_FW_MODE(mode)   ((mode) << 12)
+#define COMPHY_FW_NET(mode, idx, speed)(COMPHY_FW_MODE(mode) | 
\
+((idx) << 8) | \
+((speed) << 2))
+#define COMPHY_FW_PCIE(mode, idx, speed, width)(COMPHY_FW_NET(mode, 
idx, speed) | \
+((width) << 18))
+
+struct mvebu_a3700_comphy_conf {
+   unsigned int lane;
+   enum phy_mode mode;
+   int submode;
+   unsigned int port;
+   u32 fw_mode;
+};
+

[PATCH v5 7/7] ARM64: dts: marvell: armada-37xx: declare the COMPHY node

[Miquel Raynal]

Describe the A3700 COMPHY node. It has three PHYs that can be
configured as follow:
* PCIe or GbE
* USB3 or GbE
* SATA or USB3
Each of them has its own memory area.

Suggested-by: Grzegorz Jaszczyk 
Signed-off-by: Miquel Raynal 
---
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 29 
 1 file changed, 29 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi 
b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index e7405931f381..036d6fd6c9ef 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -242,6 +242,35 @@
reg = <0x14000 0x60>;
};
 
+   comphy: phy@18300 {
+   compatible = "marvell,comphy-a3700";
+   reg = <0x18300 0x300>,
+ <0x1F000 0x400>,
+ <0x5C000 0x400>,
+ <0xe0178 0x8>;
+   reg-names = "comphy",
+   "lane1_pcie_gbe",
+   "lane0_usb3_gbe",
+   "lane2_sata_usb3";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   comphy0: phy@0 {
+   reg = <0>;
+   #phy-cells = <1>;
+   };
+
+   comphy1: phy@1 {
+   reg = <1>;
+   #phy-cells = <1>;
+   };
+
+   comphy2: phy@2 {
+   reg = <2>;
+   #phy-cells = <1>;
+   };
+   };
+
pinctrl_sb: pinctrl@18800 {
compatible = "marvell,armada3710-sb-pinctrl",
 "syscon", "simple-mfd";
-- 
2.19.1

[PATCH v5 5/7] MAINTAINERS: phy: add entry for Armada 3700 COMPHY driver

[Miquel Raynal]

Add myself as Armada 3700 COMPHY driver/bindings maintainer.

Signed-off-by: Miquel Raynal 
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 72e930c51fd4..2ef7a60ab24b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8865,6 +8865,12 @@ F:   drivers/gpu/drm/armada/
 F: include/uapi/drm/armada_drm.h
 F: Documentation/devicetree/bindings/display/armada/
 
+MARVELL ARMADA 3700 COMPHY DRIVER
+M: Miquel Raynal 
+S: Maintained
+F: drivers/phy/marvell/phy-mvebu-a3700-comphy.c
+F: Documentation/devicetree/bindings/phy/phy-mvebu-comphy.txt
+
 MARVELL CRYPTO DRIVER
 M: Boris Brezillon 
 M: Arnaud Ebalard 
-- 
2.19.1

[PATCH v5 6/7] ARM64: dts: marvell: armada-37xx: fix SATA node scope

[Miquel Raynal]

Fix the SATA IP memory area which is only 0x178 bytes long (from
Marvell A3700 specification). Actually, starting from the offset
0xe0178, there is an area dedicated to the COMPHY driver.

Suggested-by: Grzegorz Jaszczyk 
Signed-off-by: Miquel Raynal 
---
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi 
b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index 4472bcd8f9fb..e7405931f381 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -358,7 +358,7 @@
 
sata: sata@e {
compatible = "marvell,armada-3700-ahci";
-   reg = <0xe 0x2000>;
+   reg = <0xe 0x178>;
interrupts = ;
status = "disabled";
};
-- 
2.19.1

[PATCH v5 4/7] dt-bindings: phy: mvebu-comphy: extend the file to describe a3700 bindings

[Miquel Raynal]

Current file describe COMPHY bindings for the IP available on the
CP110 of Armada 7k/8k. Bindings are very close (and serve the same
purpose) as the new Armada 3700 COMPHY driver so update this file to
describe both. Also add an example of how to use this second
compatible (same as for the ESPRESSObin).

While doing so, enhance a bit the file by adding upper case where
needed.

Signed-off-by: Miquel Raynal 
Reviewed-by: Rob Herring 
---
 .../bindings/phy/phy-mvebu-comphy.txt | 65 +++
 1 file changed, 53 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/phy-mvebu-comphy.txt 
b/Documentation/devicetree/bindings/phy/phy-mvebu-comphy.txt
index bfcf80341657..cf2cd86db267 100644
--- a/Documentation/devicetree/bindings/phy/phy-mvebu-comphy.txt
+++ b/Documentation/devicetree/bindings/phy/phy-mvebu-comphy.txt
@@ -1,16 +1,27 @@
-mvebu comphy driver

+MVEBU comphy drivers
+
 
-A comphy controller can be found on Marvell Armada 7k/8k on the CP110. It
-provides a number of shared PHYs used by various interfaces (network, sata,
-usb, PCIe...).
+COMPHY controllers can be found on the following Marvell MVEBU SoCs:
+* Armada 7k/8k (on the CP110)
+* Armada 3700
+It provides a number of shared PHYs used by various interfaces (network, SATA,
+USB, PCIe...).
 
 Required properties:
 
-- compatible: should be "marvell,comphy-cp110"
-- reg: should contain the comphy register location and length.
-- marvell,system-controller: should contain a phandle to the
- system controller node.
+- compatible: should be one of:
+  * "marvell,comphy-cp110" for Armada 7k/8k
+  * "marvell,comphy-a3700" for Armada 3700
+- reg: should contain the COMPHY register(s) location(s) and length(s).
+  * 1 entry for Armada 7k/8k
+  * 4 entries for Armada 3700 along with the corresponding reg-names
+properties, memory areas are:
+* Generic COMPHY registers
+* Lane 1 (PCIe/GbE)
+* Lane 0 (USB3/GbE)
+* Lane 2 (SATA/USB3)
+- marvell,system-controller: should contain a phandle to the system
+controller node (only for Armada 7k/8k)
 - #address-cells: should be 1.
 - #size-cells: should be 0.
 
@@ -18,11 +29,11 @@ A sub-node is required for each comphy lane provided by the 
comphy.
 
 Required properties (child nodes):
 
-- reg: comphy lane number.
-- #phy-cells : from the generic phy bindings, must be 1. Defines the
+- reg: COMPHY lane number.
+- #phy-cells : from the generic PHY bindings, must be 1. Defines the
input port to use for a given comphy lane.
 
-Example:
+Examples:
 
cpm_comphy: phy@12 {
compatible = "marvell,comphy-cp110";
@@ -41,3 +52,33 @@ Example:
#phy-cells = <1>;
};
};
+
+   comphy: phy@18300 {
+   compatible = "marvell,comphy-a3700";
+   reg = <0x18300 0x300>,
+   <0x1F000 0x400>,
+   <0x5C000 0x400>,
+   <0xe0178 0x8>;
+   reg-names = "comphy",
+   "lane1_pcie_gbe",
+   "lane0_usb3_gbe",
+   "lane2_sata_usb3";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+
+   comphy0: phy@0 {
+   reg = <0>;
+   #phy-cells = <1>;
+   };
+
+   comphy1: phy@1 {
+   reg = <1>;
+   #phy-cells = <1>;
+   };
+
+   comphy2: phy@2 {
+   reg = <2>;
+   #phy-cells = <1>;
+   };
+   };
-- 
2.19.1

[PATCH v5 2/7] phy: enumerate SATA PHY mode

[Miquel Raynal]

From: Grzegorz Jaszczyk 

Add SATA mode to the PHY framework in preparation of upcoming PHYs
that will handle it. For instance, SATA mode will be used by the
Armada3700 COMPHY driver, which supports configuring SERDES lanes to
be used by various controllers: Ethernet, USB3, SATA and PCIe.

Signed-off-by: Grzegorz Jaszczyk 
Signed-off-by: Miquel Raynal 
---
 include/linux/phy/phy.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 1fdefadf150a..7fa18b684a7d 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -42,6 +42,7 @@ enum phy_mode {
PHY_MODE_PCIE,
PHY_MODE_ETHERNET,
PHY_MODE_MIPI_DPHY,
+   PHY_MODE_SATA,
 };
 
 /**
-- 
2.19.1

[PATCH v5 1/7] phy: mvebu-cp110-comphy: fix port check in ->xlate()

[Miquel Raynal]

So far the PHY ->xlate() callback was checking if the port was
"invalid" before continuing, meaning that the port has not been used
yet. This check is not correct as there is no opposite call to
->xlate() once the PHY is released by the user and the port will
remain "valid" after the first phy_get()/phy_put() calls. Hence, if
this driver is built as a module, inserted, removed and inserted
again, the PHY will appear busy and the second probe will fail.

To fix this, just drop the faulty check and instead verify that the
port number is valid (ie. in the possible range).

Signed-off-by: Miquel Raynal 
---
 drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c 
b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
index 187cccde53b5..d98e0451f6a1 100644
--- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
+++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
@@ -580,8 +580,6 @@ static struct phy *mvebu_comphy_xlate(struct device *dev,
return phy;
 
lane = phy_get_drvdata(phy);
-   if (lane->port >= 0)
-   return ERR_PTR(-EBUSY);
lane->port = args->args[0];
 
return phy;
-- 
2.19.1

[PATCH v5 0/7] Add Armada 3700 COMPHY support

[Miquel Raynal]

Hello,

This series adds a new driver to support Armada 3700 COMPHY IP.
The series has been tested on an ESPRESSObin with SATA, PCIe
and USB3 host. For this purpose, patch 1 enumerates the SATA PHY
mode. The SGMII PHY mode that is supported by the IP has been written
(uses SMC calls anyway) but could not be tested on this platform.

Three series will follow to add PHY support (or at least a PHY nodes
in the A3700/ESPRESSObin device trees) to the MVEBU AHCI driver, the
Aardvark PCI controller driver and the MVEBU xHCI driver. All this is
needed in order to achieve suspend to RAM on this platform.

Thanks,
Miquèl


Changes since v4:
=
* Fixed error in the driver probe where PHY_INTERFACE_MODE_NA was
  assigned to lane->mode instead of lane->submode.
* Compile-in the driver by default (depends on ARCH_MVEBU).
* Add dependency on HAVE_ARM_SMCC in Kconfig.

Changes since v3:
=
* Added Rob's Reviewed-by tag on bindings.
* Rebased on top of phy -next as of the 12th of December, 2018.
* Adapted the driver to support SGMII/1000BASEX and
  HS_SGMII/2500BASEX.

Changes since v2:
=
* Remove redundant check on lane->port/args->arg[0] at the end of the
  ->xlate() callback. Do it on both armada-cp110 and armada-a3700
  COMPHY drivers.
* Put my SoB as author of the patch first when a patch is co-developed.

Changes since v1:
=
* Fix wrong check in ->xlate().
* Apply the same fix to the cp110 comphy driver from which the a3700
  driver is based.
* Added credit to Gregorz Jaszczyk for his work.
* Added Suggested-by tag to the patch adding the COMPHY DT node.


Grzegorz Jaszczyk (1):
  phy: enumerate SATA PHY mode

Miquel Raynal (6):
  phy: mvebu-cp110-comphy: fix port check in ->xlate()
  phy: add A3700 COMPHY support
  dt-bindings: phy: mvebu-comphy: extend the file to describe a3700
bindings
  MAINTAINERS: phy: add entry for Armada 3700 COMPHY driver
  ARM64: dts: marvell: armada-37xx: fix SATA node scope
  ARM64: dts: marvell: armada-37xx: declare the COMPHY node

 .../bindings/phy/phy-mvebu-comphy.txt |  65 +++-
 MAINTAINERS   |   6 +
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi  |  31 +-
 drivers/phy/marvell/Kconfig   |  12 +
 drivers/phy/marvell/Makefile  |   1 +
 drivers/phy/marvell/phy-mvebu-a3700-comphy.c  | 318 ++
 drivers/phy/marvell/phy-mvebu-cp110-comphy.c  |   2 -
 include/linux/phy/phy.h   |   1 +
 8 files changed, 421 insertions(+), 15 deletions(-)
 create mode 100644 drivers/phy/marvell/phy-mvebu-a3700-comphy.c

-- 
2.19.1

Re: [PATCH 20/20] cw1200: drop useless LIST_HEAD

[Kalle Valo]

Julia Lawall  writes:

> Drop LIST_HEAD where the variable it declares has never
> been used.
>
> The semantic patch that fixes this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> // 
> @@
> identifier x;
> @@
> - LIST_HEAD(x);
>   ... when != x
> // 
>
> Fixes: a910e4a94f692 ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN 
> chipsets")
> Signed-off-by: Julia Lawall 
>
> ---
> Successfully 0-day tested on 151 configurations.

I assume I can take this to wireless-drivers-next. If you are planning
to push this via some other tree please let me know.

-- 
Kalle Valo

Re: [PATCH] KVM: validate userspace input in kvm_clear_dirty_log_protect()

[Tomas Bortoli]

Hi Paolo,

On 1/7/19 11:42 PM, Paolo Bonzini wrote:
> On 02/01/19 18:29, Tomas Bortoli wrote:
>>  n = kvm_dirty_bitmap_bytes(memslot);
>> +
>> +if (n << 3 < log->num_pages || log->first_page > log->num_pages)
>> +return -EINVAL;
>> +
> 
> This should be
> 
>   if (log->first_page > memslot->npages ||
>   log->num_pages > memslot->npages - log->first_page)
>   return -EINVAL;
> 
> i.e. the comparison should check the last page in the range, not the
> number of pages.  In addition, using "n" is unnecessary since we do have
> the memslot.  I'll do the changes myself if you prefer, but an ack would
> be nice.
> 
> 


Yeah, I agree. Thanks for the reply and sure you can do the changes, np :)

Tomas

[PATCH 3/5] csky: fixup CACHEV1 store instruction fast retire

[guoren]

From: Guo Ren 

For I/O access, 810/807 store instruction fast retire will cause wrong
primitive. For example:

stw (clear interrupt source)
stw (unmask interrupt controller)
enable interrupt

stw is fast retire instruction. When PC is run at enable interrupt
stage, the clear interrupt source hasn't finished. It will cause another
wrong irq-enter.

So use mb() to prevent above.

Signed-off-by: Guo Ren 
Cc: Lu Baoquan 
---
 arch/csky/include/asm/io.h | 25 +
 1 file changed, 25 insertions(+)

diff --git a/arch/csky/include/asm/io.h b/arch/csky/include/asm/io.h
index ecae6b3..c1dfa9c 100644
--- a/arch/csky/include/asm/io.h
+++ b/arch/csky/include/asm/io.h
@@ -15,6 +15,31 @@ extern void iounmap(void *addr);
 extern int remap_area_pages(unsigned long address, phys_addr_t phys_addr,
size_t size, unsigned long flags);
 
+/*
+ * I/O memory access primitives. Reads are ordered relative to any
+ * following Normal memory access. Writes are ordered relative to any prior
+ * Normal memory access.
+ *
+ * For CACHEV1 (807, 810), store instruction could fast retire, so we need
+ * another mb() to prevent st fast retire.
+ *
+ * For CACHEV2 (860), store instruction with PAGE_ATTR_NO_BUFFERABLE won't
+ * fast retire.
+ */
+#define readb(c)   ({ u8  __v = readb_relaxed(c); rmb(); __v; })
+#define readw(c)   ({ u16 __v = readw_relaxed(c); rmb(); __v; })
+#define readl(c)   ({ u32 __v = readl_relaxed(c); rmb(); __v; })
+
+#ifdef CONFIG_CPU_HAS_CACHEV2
+#define writeb(v,c)({ wmb(); writeb_relaxed((v),(c)); })
+#define writew(v,c)({ wmb(); writew_relaxed((v),(c)); })
+#define writel(v,c)({ wmb(); writel_relaxed((v),(c)); })
+#else
+#define writeb(v,c)({ wmb(); writeb_relaxed((v),(c)); mb(); })
+#define writew(v,c)({ wmb(); writew_relaxed((v),(c)); mb(); })
+#define writel(v,c)({ wmb(); writel_relaxed((v),(c)); mb(); })
+#endif
+
 #define ioremap_nocache(phy, sz)   ioremap(phy, sz)
 #define ioremap_wc ioremap_nocache
 #define ioremap_wt ioremap_nocache
-- 
2.7.4

[PATCH 5/5] irqchip/csky: fixup handle_irq_perbit break irq

[guoren]

From: Guo Ren 

The handle_irq_perbit function loop every bit in hwirq local variable.

handle_irq_perbit(hwirq) {
  for_everyt_bit_in(hwirq) {
handle_domain_irq()
->irq_exit()
->invoke_softirq()
->__do_softirq()
->local_irq_enable() // Here will cause new interrupt.
  }
}

When new interrupt coming at local_irq_enable, it will finish another
interrupt handler and pull down the interrupt source. But hwirq is the
local variable for handle_irq_perbit(), it can't get new interrupt
controller pending reg status. So we need update hwirq with pending reg
in every loop.

Also change write_relax to writel could prevent stw from fast retire.
When local_irq is enabled, intc regs is really set-in.

Signed-off-by: Guo Ren 
Cc: Lu Baoquan 
---
 drivers/irqchip/irq-csky-apb-intc.c | 77 -
 1 file changed, 42 insertions(+), 35 deletions(-)

diff --git a/drivers/irqchip/irq-csky-apb-intc.c 
b/drivers/irqchip/irq-csky-apb-intc.c
index 2543bab..5a2ec43 100644
--- a/drivers/irqchip/irq-csky-apb-intc.c
+++ b/drivers/irqchip/irq-csky-apb-intc.c
@@ -95,7 +95,7 @@ static inline void setup_irq_channel(u32 magic, void __iomem 
*reg_addr)
 
/* Setup 64 channel slots */
for (i = 0; i < INTC_IRQS; i += 4)
-   writel_relaxed(build_channel_val(i, magic), reg_addr + i);
+   writel(build_channel_val(i, magic), reg_addr + i);
 }
 
 static int __init
@@ -135,16 +135,10 @@ ck_intc_init_comm(struct device_node *node, struct 
device_node *parent)
 static inline bool handle_irq_perbit(struct pt_regs *regs, u32 hwirq,
 u32 irq_base)
 {
-   u32 irq;
-
if (hwirq == 0)
return 0;
 
-   while (hwirq) {
-   irq = __ffs(hwirq);
-   hwirq &= ~BIT(irq);
-   handle_domain_irq(root_domain, irq_base + irq, regs);
-   }
+   handle_domain_irq(root_domain, irq_base + __fls(hwirq), regs);
 
return 1;
 }
@@ -154,12 +148,16 @@ static void gx_irq_handler(struct pt_regs *regs)
 {
bool ret;
 
-   do {
-   ret  = handle_irq_perbit(regs,
-   readl_relaxed(reg_base + GX_INTC_PEN31_00), 0);
-   ret |= handle_irq_perbit(regs,
-   readl_relaxed(reg_base + GX_INTC_PEN63_32), 32);
-   } while (ret);
+retry:
+   ret = handle_irq_perbit(regs,
+   readl(reg_base + GX_INTC_PEN63_32), 32);
+   if (ret)
+   goto retry;
+
+   ret = handle_irq_perbit(regs,
+   readl(reg_base + GX_INTC_PEN31_00), 0);
+   if (ret)
+   goto retry;
 }
 
 static int __init
@@ -174,14 +172,14 @@ gx_intc_init(struct device_node *node, struct device_node 
*parent)
/*
 * Initial enable reg to disable all interrupts
 */
-   writel_relaxed(0x0, reg_base + GX_INTC_NEN31_00);
-   writel_relaxed(0x0, reg_base + GX_INTC_NEN63_32);
+   writel(0x0, reg_base + GX_INTC_NEN31_00);
+   writel(0x0, reg_base + GX_INTC_NEN63_32);
 
/*
 * Initial mask reg with all unmasked, because we only use enalbe reg
 */
-   writel_relaxed(0x0, reg_base + GX_INTC_NMASK31_00);
-   writel_relaxed(0x0, reg_base + GX_INTC_NMASK63_32);
+   writel(0x0, reg_base + GX_INTC_NMASK31_00);
+   writel(0x0, reg_base + GX_INTC_NMASK63_32);
 
setup_irq_channel(0x03020100, reg_base + GX_INTC_SOURCE);
 
@@ -204,20 +202,29 @@ static void ck_irq_handler(struct pt_regs *regs)
void __iomem *reg_pen_lo = reg_base + CK_INTC_PEN31_00;
void __iomem *reg_pen_hi = reg_base + CK_INTC_PEN63_32;
 
-   do {
-   /* handle 0 - 31 irqs */
-   ret  = handle_irq_perbit(regs, readl_relaxed(reg_pen_lo), 0);
-   ret |= handle_irq_perbit(regs, readl_relaxed(reg_pen_hi), 32);
+retry:
+   /* handle 0 - 63 irqs */
+   ret = handle_irq_perbit(regs, readl(reg_pen_hi), 32);
+   if (ret)
+   goto retry;
 
-   if (nr_irq == INTC_IRQS)
-   continue;
+   ret = handle_irq_perbit(regs, readl(reg_pen_lo), 0);
+   if (ret)
+   goto retry;
+
+   if (nr_irq == INTC_IRQS)
+   return;
 
-   /* handle 64 - 127 irqs */
-   ret |= handle_irq_perbit(regs,
-   readl_relaxed(reg_pen_lo + CK_INTC_DUAL_BASE), 64);
-   ret |= handle_irq_perbit(regs,
-   readl_relaxed(reg_pen_hi + CK_INTC_DUAL_BASE), 96);
-   } while (ret);
+   /* handle 64 - 127 irqs */
+   ret = handle_irq_perbit(regs,
+   readl(reg_pen_hi + CK_INTC_DUAL_BASE), 96);
+   if (ret)
+   goto retry;
+
+   ret = handle_irq_perbit(regs,
+   readl(reg_pen_lo + CK_INTC_DUAL_BASE), 64);
+   if (ret)
+   goto retry;
 

[PATCH 4/5] csky: fixup compile error with pte_alloc

[guoren]

From: Guo Ren 

Commit: 4cf58924951e remove the address argument of pte_alloc without
modify csky related code. linux-5.0-rc1 compile failed with csky.

Remove the unnecessary address testing in pte_alloc().

Signed-off-by: Guo Ren 
Cc: Joel Fernandes (Google) 
Cc: Guenter Roeck 
Cc: Arnd Bergmann 
Cc: Linus Torvalds 
---
 arch/csky/include/asm/pgalloc.h | 43 +
 1 file changed, 18 insertions(+), 25 deletions(-)

diff --git a/arch/csky/include/asm/pgalloc.h b/arch/csky/include/asm/pgalloc.h
index bf4f4a0..d213bb4 100644
--- a/arch/csky/include/asm/pgalloc.h
+++ b/arch/csky/include/asm/pgalloc.h
@@ -24,41 +24,34 @@ static inline void pmd_populate(struct mm_struct *mm, pmd_t 
*pmd,
 
 extern void pgd_init(unsigned long *p);
 
-static inline pte_t *pte_alloc_one_kernel(struct mm_struct *mm,
-   unsigned long address)
+static inline pte_t *pte_alloc_one_kernel(struct mm_struct *mm)
 {
pte_t *pte;
-   unsigned long *kaddr, i;
+   unsigned long i;
 
-   pte = (pte_t *) __get_free_pages(GFP_KERNEL | __GFP_RETRY_MAYFAIL,
-PTE_ORDER);
-   kaddr = (unsigned long *)pte;
-   if (address & 0x8000)
-   for (i = 0; i < (PAGE_SIZE/4); i++)
-   *(kaddr + i) = 0x1;
-   else
-   clear_page(kaddr);
+   pte = (pte_t *) __get_free_page(GFP_KERNEL);
+   if (!pte)
+   return NULL;
+
+   for (i = 0; i < PAGE_SIZE/sizeof(pte_t); i++)
+   (pte + i)->pte_low = _PAGE_GLOBAL;
 
return pte;
 }
 
-static inline struct page *pte_alloc_one(struct mm_struct *mm,
-   unsigned long address)
+static inline struct page *pte_alloc_one(struct mm_struct *mm)
 {
struct page *pte;
-   unsigned long *kaddr, i;
-
-   pte = alloc_pages(GFP_KERNEL | __GFP_RETRY_MAYFAIL, PTE_ORDER);
-   if (pte) {
-   kaddr = kmap_atomic(pte);
-   if (address & 0x8000) {
-   for (i = 0; i < (PAGE_SIZE/4); i++)
-   *(kaddr + i) = 0x1;
-   } else
-   clear_page(kaddr);
-   kunmap_atomic(kaddr);
-   pgtable_page_ctor(pte);
+
+   pte = alloc_pages(GFP_KERNEL | __GFP_ZERO, 0);
+   if (!pte)
+   return NULL;
+
+   if (!pgtable_page_ctor(pte)) {
+   __free_page(pte);
+   return NULL;
}
+
return pte;
 }
 
-- 
2.7.4

[PATCH 2/5] csky: fixup relocation error with 807 & 860

[guoren]

From: Guo Ren 

810 doesn't support jsri instruction and csky-as will leave
jsri + nop for relocation. Module-probe need replace them with
lrw + jsr.

Signed-off-by: Guo Ren 
Cc: Hui Kai 
---
 arch/csky/kernel/module.c | 38 ++
 1 file changed, 22 insertions(+), 16 deletions(-)

diff --git a/arch/csky/kernel/module.c b/arch/csky/kernel/module.c
index 65abab0..0b028ee 100644
--- a/arch/csky/kernel/module.c
+++ b/arch/csky/kernel/module.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 
-#if defined(__CSKYABIV2__)
+#ifdef CONFIG_CPU_CK810
 #define IS_BSR32(hi16, lo16)   (((hi16) & 0xFC00) == 0xE000)
 #define IS_JSRI32(hi16, lo16)  ((hi16) == 0xEAE0)
 
@@ -25,6 +25,26 @@
*(uint16_t *)(addr) = 0xE8Fa;   \
*((uint16_t *)(addr) + 1) = 0x; \
 } while (0)
+
+static void jsri_2_lrw_jsr(uint32_t *location)
+{
+   uint16_t location_tmp = (uint16_t *)location;
+
+   if (IS_BSR32(*location_tmp, *(location_tmp + 1)))
+   return;
+
+   if (IS_JSRI32(*location_tmp, *(location_tmp + 1))) {
+   /* jsri 0x...  --> lrw r26, 0x... */
+   CHANGE_JSRI_TO_LRW(location);
+   /* lsli r0, r0 --> jsr r26 */
+   SET_JSR32_R26(location + 1);
+   }
+}
+#else
+static void inline jsri_2_lrw_jsr(uint32_t *location)
+{
+   return;
+}
 #endif
 
 int apply_relocate_add(Elf32_Shdr *sechdrs, const char *strtab,
@@ -35,9 +55,6 @@ int apply_relocate_add(Elf32_Shdr *sechdrs, const char 
*strtab,
Elf32_Sym   *sym;
uint32_t*location;
short   *temp;
-#if defined(__CSKYABIV2__)
-   uint16_t*location_tmp;
-#endif
 
for (i = 0; i < sechdrs[relsec].sh_size / sizeof(*rel); i++) {
/* This is where to make the change */
@@ -59,18 +76,7 @@ int apply_relocate_add(Elf32_Shdr *sechdrs, const char 
*strtab,
case R_CSKY_PCRELJSR_IMM11BY2:
break;
case R_CSKY_PCRELJSR_IMM26BY2:
-#if defined(__CSKYABIV2__)
-   location_tmp = (uint16_t *)location;
-   if (IS_BSR32(*location_tmp, *(location_tmp + 1)))
-   break;
-
-   if (IS_JSRI32(*location_tmp, *(location_tmp + 1))) {
-   /* jsri 0x...  --> lrw r26, 0x... */
-   CHANGE_JSRI_TO_LRW(location);
-   /* lsli r0, r0 --> jsr r26 */
-   SET_JSR32_R26(location + 1);
-   }
-#endif
+   jsri_2_lrw_jsr(location);
break;
case R_CSKY_ADDR_HI16:
temp = ((short  *)location) + 1;
-- 
2.7.4

[PATCH 1/5] Documentation/features: Add csky kernel features

[guoren]

From: Guo Ren 

  core/ cBPF-JIT : TODO |
  core/ eBPF-JIT : TODO |
  core/ generic-idle-thread  :  ok  |
  core/ jump-labels  : TODO |
  core/ tracehook:  ok  |
 debug/ KASAN: TODO |
 debug/ gcov-profile-all : TODO |
 debug/ kgdb : TODO |
 debug/ kprobes-on-ftrace: TODO |
 debug/ kprobes  : TODO |
 debug/ kretprobes   : TODO |
 debug/ optprobes: TODO |
 debug/ stackprotector   : TODO |
 debug/ uprobes  : TODO |
 debug/ user-ret-profiler: TODO |
io/ dma-contiguous   :  ok  |
   locking/ cmpxchg-local: TODO |
   locking/ lockdep  : TODO |
   locking/ queued-rwlocks   :  ok  |
   locking/ queued-spinlocks : TODO |
   locking/ rwsem-optimized  : TODO |
  perf/ kprobes-event: TODO |
  perf/ perf-regs: TODO |
  perf/ perf-stackdump   : TODO |
 sched/ membarrier-sync-core : TODO |
 sched/ numa-balancing   :  ..  |
   seccomp/ seccomp-filter   : TODO |
  time/ arch-tick-broadcast  : TODO |
  time/ clockevents  :  ok  |
  time/ context-tracking : TODO |
  time/ irq-time-acct: TODO |
  time/ modern-timekeeping   :  ok  |
  time/ virt-cpuacct : TODO |
vm/ ELF-ASLR : TODO |
vm/ PG_uncached  : TODO |
vm/ THP  :  ..  |
vm/ batch-unmap-tlb-flush: TODO |
vm/ huge-vmap: TODO |
vm/ ioremap_prot : TODO |
vm/ numa-memblock:  ..  |
vm/ pte_special  : TODO |

Signed-off-by: Guo Ren 
Cc: Arnd Bergmann 
---
 Documentation/features/core/cBPF-JIT/arch-support.txt  | 1 +
 Documentation/features/core/eBPF-JIT/arch-support.txt  | 1 +
 Documentation/features/core/generic-idle-thread/arch-support.txt   | 1 +
 Documentation/features/core/jump-labels/arch-support.txt   | 1 +
 Documentation/features/core/tracehook/arch-support.txt | 1 +
 Documentation/features/debug/KASAN/arch-support.txt| 1 +
 Documentation/features/debug/gcov-profile-all/arch-support.txt | 1 +
 Documentation/features/debug/kgdb/arch-support.txt | 1 +
 Documentation/features/debug/kprobes-on-ftrace/arch-support.txt| 1 +
 Documentation/features/debug/kprobes/arch-support.txt  | 1 +
 Documentation/features/debug/kretprobes/arch-support.txt   | 1 +
 Documentation/features/debug/optprobes/arch-support.txt| 1 +
 Documentation/features/debug/stackprotector/arch-support.txt   | 1 +
 Documentation/features/debug/uprobes/arch-support.txt  | 1 +
 Documentation/features/debug/user-ret-profiler/arch-support.txt| 1 +
 Documentation/features/io/dma-contiguous/arch-support.txt  | 1 +
 Documentation/features/locking/cmpxchg-local/arch-support.txt  | 1 +
 Documentation/features/locking/lockdep/arch-support.txt| 1 +
 Documentation/features/locking/queued-rwlocks/arch-support.txt | 1 +
 Documentation/features/locking/queued-spinlocks/arch-support.txt   | 1 +
 Documentation/features/locking/rwsem-optimized/arch-support.txt| 1 +
 Documentation/features/perf/kprobes-event/arch-support.txt | 1 +
 Documentation/features/perf/perf-regs/arch-support.txt | 1 +
 Documentation/features/perf/perf-stackdump/arch-support.txt| 1 +
 Documentation/features/sched/membarrier-sync-core/arch-support.txt | 1 +
 Documentation/features/sched/numa-balancing/arch-support.txt   | 1 +
 Documentation/features/seccomp/seccomp-filter/arch-support.txt | 1 +
 Documentation/features/time/arch-tick-broadcast/arch-support.txt   | 1 +
 Documentation/features/time/clockevents/arch-support.txt   | 1 +
 Documentation/features/time/context-tracking/arch-support.txt  | 1 +
 Documentation/features/time/irq-time-acct/arch-support.txt | 1 +
 Documentation/features/time/modern-timekeeping/arch-support.txt| 1 +
 Documentation/features/time/virt-cpuacct/arch-support.txt  | 1 +
 Documentation/features/vm/ELF-ASLR/arch-support.txt| 1 +
 Documentation/features/vm/PG_uncached/arch-support.txt | 1 +
 Documentation/features/vm/THP/arch-support.txt | 1 +
 Documentation/features/vm/TLB/arch-support.txt | 1 +
 Documentation/features/vm/huge-vmap/arch-support.txt   | 1 +
 Documentation/features/vm/ioremap_prot/arch-support.txt| 1 +
 Documentation/features/vm/numa-memblock/arch-support.txt   | 1 +
 Documentation/features/vm/pte_special/arch-support.txt | 1 +
 41 files changed, 41 insertions(+)

diff --git a/Documentation/features/core/cBPF-JIT/arch-support.txt 
b/Documentation/features/core/cBPF-JIT/arch-support.txt
index 

[PATCH v3 01/15] PCI: aardvark: Enlarge PIO timeout

[Miquel Raynal]

This delay has been proven to work until now, however, there is a
reproducible way to fail the driver probe because of it.

Adding the support for the PCIe gated peripheral clock that feeds the
Aardvark IP defers the Aardvark driver probe at boot time. The probe
functions calls pci_host_probe() at its end. This is where the timeout
(sometimes) resides, leading to a kernel panic the next time a
register is accessed. Here is the function call sequence:

advk_pcie_probe()
pci_host_probe()
pci_scan_root_bus_bridge()
pci_scan_child_bus_extend()
pci_scan_bridge_extend()
pci_scan_child_bus_extend()
pci_scan_slot()
pcie_aspm_init_link_state()
pcie_aspm_cap_init()

pcie_aspm_cap_init() is in charge of doing the initial ASPM state
setup (PCIe Active-State Power Management). The logic at the top of
the function is:

1/ Read upstream and downstream components' register state.
2/ Configure the common clock before checking latencies.
3/ Read again upstream and downstream component's register state.
4/ ...

Experimentation shows that while 1/ always work, 3/ sometimes timeouts
when reading the downstream components' register state. Each read
operation is handled by the following sequence:

pcie_capability_read_dword()
pci_bus_read_config_dword()
advk_pcie_rd_conf()

advk_pcie_rd_conf() just configures a few registers and polls on the
ISR bit before reading the value that has been retrieved through the
interconnect. The polling timeout of the ISR bit is set to 1ms. While
this value seems to fit most of the situations, in our case it is
sometimes crossed when reading PCI_EXP_LNKCAP (PCI link capacities)
from the downstream component. It has been measured that most of the
time that the read lasts longer than 1ms, it rises ~24ms. In my tests,
using twice this delay always works. The root cause and the reason why
the timeout only appearing when the probe is delayed is unknown
though.

Signed-off-by: Miquel Raynal 
---
 drivers/pci/controller/pci-aardvark.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/controller/pci-aardvark.c 
b/drivers/pci/controller/pci-aardvark.c
index 750081c1cb48..18120e312ae1 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -175,7 +175,7 @@
(PCIE_CONF_BUS(bus) | PCIE_CONF_DEV(PCI_SLOT(devfn))| \
 PCIE_CONF_FUNC(PCI_FUNC(devfn)) | PCIE_CONF_REG(where))
 
-#define PIO_TIMEOUT_MS 1
+#define PIO_TIMEOUT_MS 50
 
 #define LINK_WAIT_MAX_RETRIES  10
 #define LINK_WAIT_USLEEP_MIN   9
-- 
2.19.1

[PATCH v3 02/15] PCI: aardvark: Configure more registers in the configuration helper

[Miquel Raynal]

Mimic U-Boot configuration to be sure all hardware registers are set
properly. This will be needed for future S2RAM operation.

Signed-off-by: Miquel Raynal 
---
 drivers/pci/controller/pci-aardvark.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/pci/controller/pci-aardvark.c 
b/drivers/pci/controller/pci-aardvark.c
index 18120e312ae1..0f50163ae072 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -100,6 +100,8 @@
 #define PCIE_CORE_CTRL2_STRICT_ORDER_ENABLEBIT(5)
 #define PCIE_CORE_CTRL2_OB_WIN_ENABLE  BIT(6)
 #define PCIE_CORE_CTRL2_MSI_ENABLE BIT(10)
+#define PCIE_PHY_REFCLK(CONTROL_BASE_ADDR + 
0x14)
+#define PCIE_PHY_REFCLK_BUF_CTRL   0x1342
 #define PCIE_MSG_LOG_REG   (CONTROL_BASE_ADDR + 0x30)
 #define PCIE_ISR0_REG  (CONTROL_BASE_ADDR + 0x40)
 #define PCIE_MSG_PM_PME_MASK   BIT(7)
@@ -243,6 +245,9 @@ static void advk_pcie_setup_hw(struct advk_pcie *pcie)
 {
u32 reg;
 
+   /* Set HW Reference Clock Buffer Control */
+   advk_writel(pcie, PCIE_PHY_REFCLK_BUF_CTRL, PCIE_PHY_REFCLK);
+
/* Set to Direct mode */
reg = advk_readl(pcie, CTRL_CONFIG_REG);
reg &= ~(CTRL_MODE_MASK << CTRL_MODE_SHIFT);
@@ -274,6 +279,15 @@ static void advk_pcie_setup_hw(struct advk_pcie *pcie)
PCIE_CORE_CTRL2_TD_ENABLE;
advk_writel(pcie, reg, PCIE_CORE_CTRL2_REG);
 
+   /* Set PCIe Device Control and Status 1 PF0 register */
+   reg = PCIE_CORE_DEV_CTRL_STATS_RELAX_ORDER_DISABLE |
+   PCIE_CORE_DEV_CTRL_STATS_SNOOP_DISABLE;
+   advk_writel(pcie, reg, PCIE_CORE_DEV_CTRL_STATS_REG);
+
+   /* Program PCIe Control 2 to disable strict ordering */
+   reg = PCIE_CORE_CTRL2_RESERVED | PCIE_CORE_CTRL2_TD_ENABLE;
+   advk_writel(pcie, reg, PCIE_CORE_CTRL2_REG);
+
/* Set GEN2 */
reg = advk_readl(pcie, PCIE_CORE_CTRL0_REG);
reg &= ~PCIE_GEN_SEL_MSK;
-- 
2.19.1

[PATCH v3 00/15] Bring suspend to RAM support to PCIe Aardvark driver

[Miquel Raynal]

Hello,

As part of an effort to bring suspend to RAM support to Armada 3700
SoCs (main target: ESPRESSObin), this series handles the work around
the PCIe IP.

First, more configuration is done in the 'setup' helper as inspired
from the U-Boot driver. This is needed to entirely initialize the IP
during future resume operation (patch 1).

Then, reset GPIO, PHY and clock support are introduced (patch 2-4). As
current device trees do not provide the corresponding properties, not
finding one of these properties is not an error and just produces a
warning. However, if the property is present, an error during PHY
initialization will fail the probe of the driver.

Note: To be sure the clock will be resumed before this driver, a first
series adding links between clocks and consumers has been submitted,
see [1]. Anyway, having the clock series applied first is not needed.

Patch 5 adds suspend/resume hooks, re-using all the above.

Finally, bindings and device trees are updated to reflect the hardware
(patch 6-12). While the clock depends on the SoC, the reset GPIO and
the PHY depends on the board so the clock is added in the
armada-37xx.dtsi file while the two other properties are added in
armada-3720-espressobin.dts.

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2019-January/623885.html

Thanks,
Miquèl


Changes since v2:
=
* Minor patches reordering.
* Added pinctrl patches from Gregory Clement fixing the PCIe pins. His
  changes implied modifications in the DT/bindings patches adding PCIe
  reset pin support.
* Added a new patch that enlarges the PIO timeout of the driver
  (explanations in the commit log).
* With the timeout changed, removed the "experimental delay" that was
  needed at resume time before accessing any register.

Changes since v1:
=
* Change the capitalization in commit titles to follow the PCI
  subsystem rules.
* Added Suggested-by tag to the patch adding PHY support and to the
  patch adding the PHY property in the DT.
* Added Rob's Reviewed-by tags on bindings.
* I am following the discussion about calling functions that might
  sleep in a NOIRQ context. As there is no real problem yet (as per my
  understanding), I did not change anything on this regard.


Miquel Raynal (15):
  PCI: aardvark: Enlarge PIO timeout
  PCI: aardvark: Configure more registers in the configuration helper
  PCI: aardvark: Add clock support
  PCI: aardvark: Add PHY support
  PCI: aardvark: Add PCIe warm reset support
  PCI: aardvark: Add external reset GPIO support
  PCI: aardvark: Add suspend to RAM support
  dt-bindings: PCI: aardvark: Describe the clocks property
  dt-bindings: PCI: aardvark: Describe the PHY property
  dt-bindings: PCI: aardvark: Describe the PCIe endpoint card reset pins
  dt-bindings: PCI: aardvark: Describe the reset-gpios property
  ARM64: dts: marvell: armada-37xx: declare PCIe clock
  ARM64: dts: marvell: armada-3720-espressobin: declare PCIe PHY
  ARM64: dts: marvell: armada-37xx: declare PCIe reset pin
  ARM64: dts: marvell: armada-3720-espressobin: declare PCIe warm reset
pin

 .../devicetree/bindings/pci/aardvark-pci.txt  |  14 ++
 .../dts/marvell/armada-3720-espressobin.dts   |   3 +
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi  |  10 +
 drivers/pci/controller/pci-aardvark.c | 217 +-
 4 files changed, 243 insertions(+), 1 deletion(-)

-- 
2.19.1

[PATCH v3 09/15] dt-bindings: PCI: aardvark: Describe the PHY property

[Miquel Raynal]

Document the possibility to reference a PHY.

Signed-off-by: Miquel Raynal 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/pci/aardvark-pci.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/aardvark-pci.txt 
b/Documentation/devicetree/bindings/pci/aardvark-pci.txt
index 9d19ebfea189..a440f182ccf8 100644
--- a/Documentation/devicetree/bindings/pci/aardvark-pci.txt
+++ b/Documentation/devicetree/bindings/pci/aardvark-pci.txt
@@ -21,6 +21,10 @@ contain the following properties:
define the mapping of the PCIe interface to interrupt numbers.
  - bus-range: PCI bus numbers covered
 
+The following are optional properties:
+
+ - phys: the PCIe PHY handle
+
 In addition, the Device Tree describing an Aardvark PCIe controller
 must include a sub-node that describes the legacy interrupt controller
 built into the PCIe controller. This sub-node must have the following
@@ -50,6 +54,7 @@ Example:
<0 0 0 2 _intc 1>,
<0 0 0 3 _intc 2>,
<0 0 0 4 _intc 3>;
+   phys = < 0>;
pcie_intc: interrupt-controller {
interrupt-controller;
#interrupt-cells = <1>;
-- 
2.19.1

[PATCH v3 04/15] PCI: aardvark: Add PHY support

[Miquel Raynal]

The IP needs its PHY to be properly configured to work. While the PHY
is usually already configured by the bootloader, we will need this
feature when adding S2RAM support. Take care of registering and
configuring the PHY from the driver itself.

Suggested-by: Grzegorz Jaszczyk 
Signed-off-by: Miquel Raynal 
---
 drivers/pci/controller/pci-aardvark.c | 62 +++
 1 file changed, 62 insertions(+)

diff --git a/drivers/pci/controller/pci-aardvark.c 
b/drivers/pci/controller/pci-aardvark.c
index b1b8897d2d28..27ec79defa57 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -203,6 +204,7 @@ struct advk_pcie {
u16 msi_msg;
int root_bus_nr;
struct pci_bridge_emul bridge;
+   struct phy *phy;
 };
 
 static inline void advk_writel(struct advk_pcie *pcie, u32 val, u64 reg)
@@ -998,6 +1000,62 @@ static int advk_pcie_setup_clk(struct advk_pcie *pcie)
return ret;
 }
 
+static void __maybe_unused advk_pcie_disable_phy(struct advk_pcie *pcie)
+{
+   phy_power_off(pcie->phy);
+   phy_exit(pcie->phy);
+}
+
+static int advk_pcie_enable_phy(struct advk_pcie *pcie)
+{
+   int ret;
+
+   if (!pcie->phy)
+   return 0;
+
+   ret = phy_init(pcie->phy);
+   if (ret)
+   return ret;
+
+   ret = phy_set_mode(pcie->phy, PHY_MODE_PCIE);
+   if (ret) {
+   phy_exit(pcie->phy);
+   return ret;
+   }
+
+   ret = phy_power_on(pcie->phy);
+   if (ret) {
+   phy_exit(pcie->phy);
+   return ret;
+   }
+
+   return 0;
+}
+
+static int advk_pcie_setup_phy(struct advk_pcie *pcie)
+{
+   struct device *dev = >pdev->dev;
+   struct device_node *node = dev->of_node;
+   int ret = 0;
+
+   pcie->phy = devm_of_phy_get(dev, node, NULL);
+   if (IS_ERR(pcie->phy) && (PTR_ERR(pcie->phy) == -EPROBE_DEFER))
+   return PTR_ERR(pcie->phy);
+
+   /* Old bindings miss the PHY handle */
+   if (IS_ERR(pcie->phy)) {
+   dev_warn(dev, "PHY unavailable (%ld)\n", PTR_ERR(pcie->phy));
+   pcie->phy = NULL;
+   return 0;
+   }
+
+   ret = advk_pcie_enable_phy(pcie);
+   if (ret)
+   dev_err(dev, "Failed to initialize PHY (%d)\n", ret);
+
+   return ret;
+}
+
 static int advk_pcie_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -1037,6 +1095,10 @@ static int advk_pcie_probe(struct platform_device *pdev)
if (ret)
return ret;
 
+   ret = advk_pcie_setup_phy(pcie);
+   if (ret)
+   return ret;
+
advk_pcie_setup_hw(pcie);
 
advk_sw_pci_bridge_init(pcie);
-- 
2.19.1

[PATCH v3 07/15] PCI: aardvark: Add suspend to RAM support

[Miquel Raynal]

Add suspend and resume callbacks. The priority of these are
"_noirq()", to workaround early access to the registers done by the
PCI core through the ->read()/->write() callbacks at resume time.

Signed-off-by: Miquel Raynal 
---
 drivers/pci/controller/pci-aardvark.c | 45 ++-
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/controller/pci-aardvark.c 
b/drivers/pci/controller/pci-aardvark.c
index 3fb14e37eb59..999bbe27761a 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -1028,7 +1028,7 @@ static int advk_pcie_setup_clk(struct advk_pcie *pcie)
return ret;
 }
 
-static void __maybe_unused advk_pcie_disable_phy(struct advk_pcie *pcie)
+static void advk_pcie_disable_phy(struct advk_pcie *pcie)
 {
phy_power_off(pcie->phy);
phy_exit(pcie->phy);
@@ -1119,6 +1119,47 @@ static int advk_pcie_setup_reset_gpio(struct advk_pcie 
*pcie)
return 0;
 }
 
+static int __maybe_unused advk_pcie_suspend(struct device *dev)
+{
+   struct advk_pcie *pcie = dev_get_drvdata(dev);
+
+   advk_pcie_disable_phy(pcie);
+
+   clk_disable_unprepare(pcie->clk);
+
+   return 0;
+}
+
+static int __maybe_unused advk_pcie_resume(struct device *dev)
+{
+   struct advk_pcie *pcie = dev_get_drvdata(dev);
+   int ret;
+
+   ret = clk_prepare_enable(pcie->clk);
+   if (ret)
+   return ret;
+
+   ret = advk_pcie_enable_phy(pcie);
+   if (ret)
+   return ret;
+
+   advk_pcie_setup_hw(pcie);
+
+   advk_sw_pci_bridge_init(pcie);
+
+   return 0;
+}
+
+/*
+ * The PCI core will try to reconfigure the bus quite early in the resume path.
+ * We must use the _noirq() alternatives to ensure the controller is ready when
+ * the core uses the ->read()/->write() callbacks.
+ */
+static const struct dev_pm_ops advk_pcie_dev_pm_ops = {
+   SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(advk_pcie_suspend,
+ advk_pcie_resume)
+};
+
 static int advk_pcie_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -1133,6 +1174,7 @@ static int advk_pcie_probe(struct platform_device *pdev)
 
pcie = pci_host_bridge_priv(bridge);
pcie->pdev = pdev;
+   platform_set_drvdata(pdev, pcie);
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
pcie->base = devm_ioremap_resource(dev, res);
@@ -1210,6 +1252,7 @@ static struct platform_driver advk_pcie_driver = {
.driver = {
.name = "advk-pcie",
.of_match_table = advk_pcie_of_match_table,
+   .pm = _pcie_dev_pm_ops,
/* Driver unloading/unbinding currently not supported */
.suppress_bind_attrs = true,
},
-- 
2.19.1

[PATCH v3 08/15] dt-bindings: PCI: aardvark: Describe the clocks property

[Miquel Raynal]

Describe the missing gated clock feeding the PCIe IP.

Signed-off-by: Miquel Raynal 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/pci/aardvark-pci.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/aardvark-pci.txt 
b/Documentation/devicetree/bindings/pci/aardvark-pci.txt
index 310ef7145c47..9d19ebfea189 100644
--- a/Documentation/devicetree/bindings/pci/aardvark-pci.txt
+++ b/Documentation/devicetree/bindings/pci/aardvark-pci.txt
@@ -12,6 +12,7 @@ contain the following properties:
  - #size-cells: set to <2>
  - device_type: set to "pci"
  - ranges: ranges for the PCI memory and I/O regions
+ - clocks: the clock feeding the IP
  - #interrupt-cells: set to <1>
  - msi-controller: indicates that the PCIe controller can itself
handle MSI interrupts
@@ -37,6 +38,7 @@ Example:
#address-cells = <3>;
#size-cells = <2>;
bus-range = <0x00 0xff>;
+   clocks = <_periph_clk 13>;
interrupts = ;
#interrupt-cells = <1>;
msi-controller;
-- 
2.19.1

[PATCH v3 03/15] PCI: aardvark: Add clock support

[Miquel Raynal]

The IP relies on a gated clock. When we will add S2RAM support, this
clock will need to be resumed before any PCIe registers are
accessed. Add support for this clock.

Signed-off-by: Miquel Raynal 
---
 drivers/pci/controller/pci-aardvark.c | 29 +++
 1 file changed, 29 insertions(+)

diff --git a/drivers/pci/controller/pci-aardvark.c 
b/drivers/pci/controller/pci-aardvark.c
index 0f50163ae072..b1b8897d2d28 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -8,6 +8,7 @@
  * Author: Hezi Shahmoon 
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -187,6 +188,7 @@
 
 struct advk_pcie {
struct platform_device *pdev;
+   struct clk *clk;
void __iomem *base;
struct list_head resources;
struct irq_domain *irq_domain;
@@ -973,6 +975,29 @@ static int advk_pcie_parse_request_of_pci_ranges(struct 
advk_pcie *pcie)
return err;
 }
 
+static int advk_pcie_setup_clk(struct advk_pcie *pcie)
+{
+   struct device *dev = >pdev->dev;
+   int ret;
+
+   pcie->clk = devm_clk_get(dev, NULL);
+   if (IS_ERR(pcie->clk) && (PTR_ERR(pcie->clk) == -EPROBE_DEFER))
+   return PTR_ERR(pcie->clk);
+
+   /* Old bindings miss the clock handle */
+   if (IS_ERR(pcie->clk)) {
+   dev_warn(dev, "Clock unavailable (%ld)\n", PTR_ERR(pcie->clk));
+   pcie->clk = NULL;
+   return 0;
+   }
+
+   ret = clk_prepare_enable(pcie->clk);
+   if (ret)
+   dev_err(dev, "Clock initialization failed (%d)\n", ret);
+
+   return ret;
+}
+
 static int advk_pcie_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -1008,6 +1033,10 @@ static int advk_pcie_probe(struct platform_device *pdev)
return ret;
}
 
+   ret = advk_pcie_setup_clk(pcie);
+   if (ret)
+   return ret;
+
advk_pcie_setup_hw(pcie);
 
advk_sw_pci_bridge_init(pcie);
-- 
2.19.1

[PATCH v3 10/15] dt-bindings: PCI: aardvark: Describe the PCIe endpoint card reset pins

[Miquel Raynal]

A line might be used by the PCIe IP to reset the endpoint card upon:
  - platform reset,
  - hot reset,
  - link failure.

Describe the properties needed in this case (optional).

Signed-off-by: Miquel Raynal 
---
 Documentation/devicetree/bindings/pci/aardvark-pci.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/aardvark-pci.txt 
b/Documentation/devicetree/bindings/pci/aardvark-pci.txt
index a440f182ccf8..8b7f048705ec 100644
--- a/Documentation/devicetree/bindings/pci/aardvark-pci.txt
+++ b/Documentation/devicetree/bindings/pci/aardvark-pci.txt
@@ -24,6 +24,9 @@ contain the following properties:
 The following are optional properties:
 
  - phys: the PCIe PHY handle
+ - pinctrl-names: must be "default".
+ - pinctrl-0: pin control group to be used to mux the PCIe endpoint card
+   reset line so that it will be automatically driven by the PCIe IP.
 
 In addition, the Device Tree describing an Aardvark PCIe controller
 must include a sub-node that describes the legacy interrupt controller
@@ -55,6 +58,8 @@ Example:
<0 0 0 3 _intc 2>,
<0 0 0 4 _intc 3>;
phys = < 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_card_reset_pins _clkreq_pins>;
pcie_intc: interrupt-controller {
interrupt-controller;
#interrupt-cells = <1>;
-- 
2.19.1

[PATCH v3 11/15] dt-bindings: PCI: aardvark: Describe the reset-gpios property

[Miquel Raynal]

A GPIO might be used to reset the PCI IP. Describe the property needed
in this case.

Signed-off-by: Miquel Raynal 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/pci/aardvark-pci.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/aardvark-pci.txt 
b/Documentation/devicetree/bindings/pci/aardvark-pci.txt
index 8b7f048705ec..b47d6d608ae1 100644
--- a/Documentation/devicetree/bindings/pci/aardvark-pci.txt
+++ b/Documentation/devicetree/bindings/pci/aardvark-pci.txt
@@ -27,6 +27,8 @@ The following are optional properties:
  - pinctrl-names: must be "default".
  - pinctrl-0: pin control group to be used to mux the PCIe endpoint card
reset line so that it will be automatically driven by the PCIe IP.
+ - reset-gpios: GPIO to reset the device (alternative to the above
+   entries that represent a pin controlled by the PCI IP itself).
 
 In addition, the Device Tree describing an Aardvark PCIe controller
 must include a sub-node that describes the legacy interrupt controller
-- 
2.19.1

[PATCH v3 12/15] ARM64: dts: marvell: armada-37xx: declare PCIe clock

[Miquel Raynal]

The PCIe IP is fed by a gated clock.

Signed-off-by: Miquel Raynal 
---
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi 
b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index 65bf774516ec..f6f8d2b3b2c1 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -414,6 +414,7 @@
#address-cells = <3>;
#size-cells = <2>;
bus-range = <0x00 0xff>;
+   clocks = <_periph_clk 13>;
interrupts = ;
#interrupt-cells = <1>;
msi-parent = <>;
-- 
2.19.1

[PATCH v3 06/15] PCI: aardvark: Add external reset GPIO support

[Miquel Raynal]

Add support for a possible external reset GPIO wired to the PCIe
endpoint card. Asserting/deasserting the reset line is done during the
warm reset because the warm reset operation already triggers the
internal reset line that may also reset the endpoint card (if muxed).

Signed-off-by: Miquel Raynal 
---
 drivers/pci/controller/pci-aardvark.c | 50 +++
 1 file changed, 50 insertions(+)

diff --git a/drivers/pci/controller/pci-aardvark.c 
b/drivers/pci/controller/pci-aardvark.c
index cfe48e553bca..3fb14e37eb59 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -19,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "../pci.h"
@@ -209,6 +211,7 @@ struct advk_pcie {
int root_bus_nr;
struct pci_bridge_emul bridge;
struct phy *phy;
+   struct gpio_desc *reset_gpio;
 };
 
 static inline void advk_writel(struct advk_pcie *pcie, u32 val, u64 reg)
@@ -249,6 +252,12 @@ static int advk_pcie_wait_for_link(struct advk_pcie *pcie)
return -ETIMEDOUT;
 }
 
+static void advk_pcie_card_reset_assert(struct advk_pcie *pcie, bool status)
+{
+   if (pcie->reset_gpio)
+   gpiod_set_value_cansleep(pcie->reset_gpio, status);
+}
+
 static void advk_pcie_setup_hw(struct advk_pcie *pcie)
 {
u32 reg;
@@ -257,11 +266,13 @@ static void advk_pcie_setup_hw(struct advk_pcie *pcie)
reg = advk_readl(pcie, CTRL_WARM_RESET_REG);
reg |= CTRL_PCIE_CORE_WARM_RESET | CTRL_PHY_CORE_WARM_RESET |
   CTRL_PERSTN_GPIO_EN;
+   advk_pcie_card_reset_assert(pcie, 1);
advk_writel(pcie, reg, CTRL_WARM_RESET_REG);
reg = advk_readl(pcie, CTRL_WARM_RESET_REG);
mdelay(1);
reg &= ~(CTRL_PCIE_CORE_WARM_RESET | CTRL_PHY_CORE_WARM_RESET |
 CTRL_PERSTN_GPIO_EN);
+   advk_pcie_card_reset_assert(pcie, 0);
advk_writel(pcie, reg, CTRL_WARM_RESET_REG);
reg = advk_readl(pcie, CTRL_WARM_RESET_REG);
mdelay(10);
@@ -1073,6 +1084,41 @@ static int advk_pcie_setup_phy(struct advk_pcie *pcie)
return ret;
 }
 
+static int advk_pcie_setup_reset_gpio(struct advk_pcie *pcie)
+{
+   struct device *dev = >pdev->dev;
+   enum of_gpio_flags of_flags;
+   unsigned long gpio_flags;
+   int gpio_nb;
+   int ret;
+
+   gpio_nb = of_get_named_gpio_flags(dev->of_node, "reset-gpios", 0,
+ _flags);
+   if (gpio_nb == -EPROBE_DEFER)
+   return gpio_nb;
+
+   /* No all boards use an external GPIO for card reset */
+   if (!gpio_is_valid(gpio_nb))
+   return 0;
+
+   if (of_flags & OF_GPIO_ACTIVE_LOW)
+   gpio_flags = GPIOF_ACTIVE_LOW |
+GPIOF_OUT_INIT_LOW;
+   else
+   gpio_flags = GPIOF_OUT_INIT_HIGH;
+
+   ret = devm_gpio_request_one(dev, gpio_nb, gpio_flags,
+   "pcie-aardvark-card-reset");
+   if (ret) {
+   dev_err(dev, "Failed to retrieve reset GPIO (%d)\n", ret);
+   return ret;
+   }
+
+   pcie->reset_gpio = gpio_to_desc(gpio_nb);
+
+   return 0;
+}
+
 static int advk_pcie_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -1116,6 +1162,10 @@ static int advk_pcie_probe(struct platform_device *pdev)
if (ret)
return ret;
 
+   ret = advk_pcie_setup_reset_gpio(pcie);
+   if (ret)
+   return ret;
+
advk_pcie_setup_hw(pcie);
 
advk_sw_pci_bridge_init(pcie);
-- 
2.19.1

[PATCH v3 05/15] PCI: aardvark: Add PCIe warm reset support

[Miquel Raynal]

Make use of the 'warm reset' register to ensure every peace of
hardware (core, phy, endpoint card) are in a known state before doing
the hardware setup.

The Aardvark IP can trigger a reset signal upon hot reset or link
failure that will only reach the components on the board without
affecting the entire device (eg. only the endpoint card). This line is
multiplexed on MPPs so if it is not used as PCI reset and multiplexed
for instance as a GPIO, the signals produced by the PCIe IP during the
warm reset operation won't affect the state of the line.

As usual, hardware designers can implement a card reset wired to a
GPIO. Support for such reset GPIO will be added in another patch.

Signed-off-by: Miquel Raynal 
---
 drivers/pci/controller/pci-aardvark.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/pci/controller/pci-aardvark.c 
b/drivers/pci/controller/pci-aardvark.c
index 27ec79defa57..cfe48e553bca 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -139,6 +139,10 @@
 #define CTRL_MODE_MASK 0x1
 #define PCIE_CORE_MODE_DIRECT  0x0
 #define PCIE_CORE_MODE_COMMAND 0x1
+#define CTRL_WARM_RESET_REG(CTRL_CORE_BASE_ADDR + 0x4)
+#define CTRL_PCIE_CORE_WARM_RESET  BIT(0)
+#define CTRL_PHY_CORE_WARM_RESET   BIT(1)
+#define CTRL_PERSTN_GPIO_ENBIT(3)
 
 /* PCIe Central Interrupts Registers */
 #define CENTRAL_INT_BASE_ADDR  0x1b000
@@ -249,6 +253,19 @@ static void advk_pcie_setup_hw(struct advk_pcie *pcie)
 {
u32 reg;
 
+   /* Warm reset */
+   reg = advk_readl(pcie, CTRL_WARM_RESET_REG);
+   reg |= CTRL_PCIE_CORE_WARM_RESET | CTRL_PHY_CORE_WARM_RESET |
+  CTRL_PERSTN_GPIO_EN;
+   advk_writel(pcie, reg, CTRL_WARM_RESET_REG);
+   reg = advk_readl(pcie, CTRL_WARM_RESET_REG);
+   mdelay(1);
+   reg &= ~(CTRL_PCIE_CORE_WARM_RESET | CTRL_PHY_CORE_WARM_RESET |
+CTRL_PERSTN_GPIO_EN);
+   advk_writel(pcie, reg, CTRL_WARM_RESET_REG);
+   reg = advk_readl(pcie, CTRL_WARM_RESET_REG);
+   mdelay(10);
+
/* Set HW Reference Clock Buffer Control */
advk_writel(pcie, PCIE_PHY_REFCLK_BUF_CTRL, PCIE_PHY_REFCLK);
 
-- 
2.19.1

[PATCH v3 15/15] ARM64: dts: marvell: armada-3720-espressobin: declare PCIe warm reset pin

[Miquel Raynal]

Ensure the PCIe endpoint card reset that is toggled by the PCIe
controller itself is muxed correctly on the EspressoBin.

Signed-off-by: Miquel Raynal 
---
 arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts 
b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
index c5c72902c647..f19c1ecd5703 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
@@ -47,6 +47,8 @@
  {
status = "okay";
phys = < 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_reset_pins _clkreq_pins>;
 };
 
 /* J6 */
-- 
2.19.1

[PATCH v3 13/15] ARM64: dts: marvell: armada-3720-espressobin: declare PCIe PHY

[Miquel Raynal]

The PCIe node is wired to the second PHY of the COMPHY IP.

Suggested-by: Grzegorz Jaszczyk 
Signed-off-by: Miquel Raynal 
---
 arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts 
b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
index 094994a9c68e..c5c72902c647 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
@@ -46,6 +46,7 @@
 /* J9 */
  {
status = "okay";
+   phys = < 0>;
 };
 
 /* J6 */
-- 
2.19.1

[PATCH v3 14/15] ARM64: dts: marvell: armada-37xx: declare PCIe reset pin

[Miquel Raynal]

One pin can be muxed as PCIe endpoint card reset.

Signed-off-by: Miquel Raynal 
---
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi 
b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index f6f8d2b3b2c1..91c0ec9c382b 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -295,6 +295,15 @@
function = "mii";
};
 
+   pcie_reset_pins: pcie-reset-pins {
+   groups = "pcie1";
+   function = "pcie";
+   };
+
+   pcie_clkreq_pins: pcie-clkreq-pins {
+   groups = "pcie1_clkreq";
+   function = "pcie";
+   };
};
 
eth0: ethernet@3 {
-- 
2.19.1

Re: [PATCH 3/3] drivers: usb :fsl: Remove USB Errata checking code

[Alan Stern]

On Tue, 8 Jan 2019, Ran Wang wrote:

> From: yinbo.zhu 
> 
> Remove USB errata checking code from driver. Applicability of erratum
> is retrieved by reading corresponding property in device tree.
> This property is written during device tree fixup.
> 
> Signed-off-by: Ramneek Mehresh 
> Signed-off-by: Nikhil Badola 
> Signed-off-by: yinbo.zhu 
> Signed-off-by: Ran Wang 
> ---
>  drivers/usb/host/ehci-fsl.c  |7 +--
>  drivers/usb/host/fsl-mph-dr-of.c |6 ++
>  include/linux/fsl_devices.h  |7 ---
>  3 files changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
> index 59ebe1b..2aa408a 100644
> --- a/drivers/usb/host/ehci-fsl.c
> +++ b/drivers/usb/host/ehci-fsl.c
> @@ -304,14 +304,9 @@ static int ehci_fsl_usb_setup(struct ehci_hcd *ehci)
>   return -EINVAL;
>  
>   if (pdata->operating_mode == FSL_USB2_MPH_HOST) {
> - unsigned int chip, rev, svr;
> -
> - svr = mfspr(SPRN_SVR);
> - chip = svr >> 16;
> - rev = (svr >> 4) & 0xf;
>  
>   /* Deal with USB Erratum #14 on MPC834x Rev 1.0 & 1.1 chips */
> - if ((rev == 1) && (chip >= 0x8050) && (chip <= 0x8055))
> + if (pdata->has_fsl_erratum_14 == 1)
>   ehci->has_fsl_port_bug = 1;
>  
>   if (pdata->port_enables & FSL_USB2_PORT0_ENABLED)
> diff --git a/drivers/usb/host/fsl-mph-dr-of.c 
> b/drivers/usb/host/fsl-mph-dr-of.c
> index 677f9d5..4f8b8a0 100644
> --- a/drivers/usb/host/fsl-mph-dr-of.c
> +++ b/drivers/usb/host/fsl-mph-dr-of.c
> @@ -225,6 +225,12 @@ static int fsl_usb2_mph_dr_of_probe(struct 
> platform_device *ofdev)
>   pdata->has_fsl_erratum_a005697 =
>   of_property_read_bool(np, "fsl,usb_erratum-a005697");
>  
> + if (of_get_property(np, "fsl,usb_erratum_14", NULL))
> + pdata->has_fsl_erratum_14 = 1;
> + else
> + pdata->has_fsl_erratum_14 = 0;
> +
> +
>   /*
>* Determine whether phy_clk_valid needs to be checked
>* by reading property in device tree
> diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
> index 60cef82..7aa51bc 100644
> --- a/include/linux/fsl_devices.h
> +++ b/include/linux/fsl_devices.h
> @@ -98,10 +98,11 @@ struct fsl_usb2_platform_data {
>  
>   unsignedsuspended:1;
>   unsignedalready_suspended:1;
> - unsignedhas_fsl_erratum_a007792:1;
> - unsignedhas_fsl_erratum_a005275:1;
> + unsignedhas_fsl_erratum_a007792:1;
> + unsignedhas_fsl_erratum_14:1;
> + unsignedhas_fsl_erratum_a005275:1;
>   unsignedhas_fsl_erratum_a005697:1;
> - unsignedcheck_phy_clk_valid:1;
> + unsignedcheck_phy_clk_valid:1;

You are using spaces here instead of tabs, which alters the alignment.  
Don't do that.

Alan Stern

>  
>   /* register save area for suspend/resume */
>   u32 pm_command;

[PATCH] qxl: Use struct_size() in kzalloc()

[Gustavo A. R. Silva]

One of the more common cases of allocation size calculations is finding the
size of a structure that has a zero-sized array at the end, along with memory
for some number of elements for that array. For example:

struct foo {
int stuff;
void *entry[];
};

instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);

Instead of leaving these open-coded and prone to type mistakes, we can now
use the new struct_size() helper:

instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);

This code was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/qxl/qxl_display.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index ce0b9c40fc21..c8642712412e 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -48,8 +48,8 @@ static int qxl_alloc_client_monitors_config(struct qxl_device 
*qdev,
}
if (!qdev->client_monitors_config) {
qdev->client_monitors_config = kzalloc(
-   sizeof(struct qxl_monitors_config) +
-   sizeof(struct qxl_head) * count, GFP_KERNEL);
+   struct_size(qdev->client_monitors_config,
+   heads, count), GFP_KERNEL);
if (!qdev->client_monitors_config)
return -ENOMEM;
}
-- 
2.20.1

Re: [PATCH v5 0/7] mfd / platform: cros_ec: move cros_ec sysfs attributes to its own drivers.

[Enric Balletbo Serra]

Hi Lee,

Missatge de Lee Jones  del dia dv., 21 de des.
2018 a les 16:39:
>
> On Wed, 12 Dec 2018, Enric Balletbo i Serra wrote:
>
> > Hi,
> >
> > This is another patchset to try to cleanup a bit more the crossed
> > references for cros-ec driver between the MFD and the platform/chrome
> > subsystems.
> >
> > The purpose of these patches is get rid of the different cros-ec attributes
> > from mfd/cros_ec_dev to its own sub-driver in platform/chrome. cros_ec_dev
> > continues instantiating the sub-devices but the sysfs attributes are owned
> > by the platform driver.E.g. The lightbar driver should own his sysfs
> > attributes and be instantiated only if the Embedded Controller has a
> > lightbar.
> >
> > The patchset also adds the documentation of the sysfs attributes.
> >
> > Most of the patches touches mfd subsystem and platform/chrome so I'd
> > suggest go all using and inmutable branch.
>
> That's fine.
>
> What else needs to happen with this set?
>

I think the patchset is ready to be queued. Note that to apply cleanly
it depends on [1] which is already merged in your for-next branch.
What do you prefer, go through your repo or go through the
chrome-platform repo? Do you want Benson or I create an immutable
branch? I'm fine with whenever you decide.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git/commit/?h=for-mfd-next=18e294ddafaeb80a1e2e10c9bd750a6cb8388d5b

> Any more Acks required?
>

I think that you, Guenter, Benson and I are fine with it, so not more
acks needed.

Thanks,
 Enric

> --
> Lee Jones [李琼斯]
> Linaro Services Technical Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 2/3] usb: ehci: fsl: Update register accessing for arm/arm64 platforms

[Alan Stern]

On Tue, 8 Jan 2019, Ran Wang wrote:

> arm/arm64's io.h doesn't define clrbits32() and clrsetbits_be32(), which
> causing compile failure on some Layerscape Platforms (such as LS1021A and
> LS2012A which also integrates FSL EHCI controller). So use
> ioread32be()/iowrite32be() instead to make it workable on both
> powerpc and arm.
> 
> Signed-off-by: Ran Wang 
> ---
>  drivers/usb/host/ehci-fsl.c |   64 
> ---
>  1 files changed, 42 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
> index 0a9fd20..59ebe1b 100644
> --- a/drivers/usb/host/ehci-fsl.c
> +++ b/drivers/usb/host/ehci-fsl.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "ehci.h"
>  #include "ehci-fsl.h"
> @@ -50,6 +51,7 @@ static int fsl_ehci_drv_probe(struct platform_device *pdev)
>   struct resource *res;
>   int irq;
>   int retval;
> + u32 tmp;
>  
>   pr_debug("initializing FSL-SOC USB Controller\n");
>  
> @@ -114,18 +116,23 @@ static int fsl_ehci_drv_probe(struct platform_device 
> *pdev)
>   }
>  
>   /* Enable USB controller, 83xx or 8536 */
> - if (pdata->have_sysif_regs && pdata->controller_ver < FSL_USB_VER_1_6)
> - clrsetbits_be32(hcd->regs + FSL_SOC_USB_CTRL,
> - CONTROL_REGISTER_W1C_MASK, 0x4);
> -
> + if (pdata->have_sysif_regs && pdata->controller_ver < FSL_USB_VER_1_6) {
> + tmp = ioread32be(hcd->regs + FSL_SOC_USB_CTRL);
> + tmp &= ~CONTROL_REGISTER_W1C_MASK;
> + tmp |= 0x4;
> + iowrite32be(tmp, hcd->regs + FSL_SOC_USB_CTRL);
> + }
>   /*
>* Enable UTMI phy and program PTS field in UTMI mode before asserting
>* controller reset for USB Controller version 2.5
>*/
>   if (pdata->has_fsl_erratum_a007792) {
> - clrsetbits_be32(hcd->regs + FSL_SOC_USB_CTRL,
> - CONTROL_REGISTER_W1C_MASK, CTRL_UTMI_PHY_EN);
> - writel(PORT_PTS_UTMI, hcd->regs + FSL_SOC_USB_PORTSC1);
> + tmp = ioread32be(hcd->regs + FSL_SOC_USB_CTRL);
> + tmp &= ~CONTROL_REGISTER_W1C_MASK;
> + tmp |= CTRL_UTMI_PHY_EN;
> + iowrite32be(tmp, hcd->regs + FSL_SOC_USB_CTRL);
> +
> + iowrite32be(PORT_PTS_UTMI, hcd->regs + FSL_SOC_USB_PORTSC1);

Why do you change this writel() into iowrite32be() but leave other 
instances of writel() unchanged?  Was this a mistake?

>   }
>  
>   /* Don't need to set host mode here. It will be done by tdi_reset() */
> @@ -174,7 +181,7 @@ static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
>  enum fsl_usb2_phy_modes phy_mode,
>  unsigned int port_offset)
>  {
> - u32 portsc;
> + u32 portsc, tmp;
>   struct ehci_hcd *ehci = hcd_to_ehci(hcd);
>   void __iomem *non_ehci = hcd->regs;
>   struct device *dev = hcd->self.controller;
> @@ -192,11 +199,16 @@ static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
>   case FSL_USB2_PHY_ULPI:
>   if (pdata->have_sysif_regs && pdata->controller_ver) {
>   /* controller version 1.6 or above */
> - clrbits32(non_ehci + FSL_SOC_USB_CTRL,
> -   CONTROL_REGISTER_W1C_MASK | UTMI_PHY_EN);
> - clrsetbits_be32(non_ehci + FSL_SOC_USB_CTRL,
> - CONTROL_REGISTER_W1C_MASK,
> - ULPI_PHY_CLK_SEL | USB_CTRL_USB_EN);
> + /* turn off UTMI PHY first */
> + tmp = ioread32be(non_ehci + FSL_SOC_USB_CTRL);
> + tmp &= ~(CONTROL_REGISTER_W1C_MASK | UTMI_PHY_EN);
> + iowrite32be(tmp, non_ehci + FSL_SOC_USB_CTRL);
> +
> + /* then turn on ULPI and enable USB controller */
> + tmp = ioread32be(non_ehci + FSL_SOC_USB_CTRL);
> + tmp &= ~(CONTROL_REGISTER_W1C_MASK);

Unnecessary parens.

> + tmp |= ULPI_PHY_CLK_SEL | USB_CTRL_USB_EN;
> + iowrite32be(tmp, non_ehci + FSL_SOC_USB_CTRL);
>   }
>   portsc |= PORT_PTS_ULPI;
>   break;
> @@ -210,16 +222,21 @@ static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
>   case FSL_USB2_PHY_UTMI_DUAL:
>   if (pdata->have_sysif_regs && pdata->controller_ver) {
>   /* controller version 1.6 or above */
> - clrsetbits_be32(non_ehci + FSL_SOC_USB_CTRL,
> - CONTROL_REGISTER_W1C_MASK, UTMI_PHY_EN);
> + tmp = ioread32be(non_ehci + FSL_SOC_USB_CTRL);
> + tmp &= ~(CONTROL_REGISTER_W1C_MASK);

Unnecessary parens.

> + tmp |= UTMI_PHY_EN;
> + iowrite32be(tmp, non_ehci + 

[PATCH v4 0/4] Add device links to clocks

[Miquel Raynal]

Hello,

While working on suspend to RAM feature, I ran into troubles multiple
times when clocks where not suspending/resuming at the desired time. I
had a look at the core and I think the same logic as in the
regulator's core may be applied here to (very easily) fix this issue:
using device links.

The only additional change I had to do was to always (when available)
populate the device entry of the core clock structure so that it could
be used later. This is the purpose of patch 1. Patch 2 actually adds
support for device links.

Here is a step-by-step explanation of how links are managed, following
Maxime Ripard's suggestion.


The order of probe has no importance because the framework already
handles orphaned clocks so let's be simple and say there are two root
clocks, not depending on anything, that are probed first: xtal0 and
xtal1. None of these clocks have a parent, there is no device link in
the game, yet.

   ++++
   ||||
   ||||
   |   xtal0 core   ||   xtal1 core   |
   ||||
   ||||
   +---^^---++---^^---+
   ||||
   ||||
   ++++
   ||||
   |   xtal0 clk||   xtal1 clk|
   ||||
   ++++

Then, a peripheral clock periph0 is probed. His parent is xtal1. The
clock_register_*() call will run __clk_init_parent() and a link between
periph0's core and xtal1's core will be created and stored in
periph0's core->parent_clk_link entry.

   ++++
   ||||
   ||||
   |   xtal0 core   ||   xtal1 core   |
   ||||
   ||||
   +---^^---++---^^---+
   ||||
   ||||
   ++++
   ||||
   |   xtal0 clk||   xtal1 clk|
   ||||
   +++---^+
 |
 |
  +--+
  |   ->parent_clk_link
  |
  ++
  ||
  ||
  |  periph0 core  |
  ||
  ||
  +---^^---+
  ||
  ||
  ++
  ||
  |  periph0 clk 0 |
  ||
  ++

Then, device0 is probed and "get" the periph0 clock. clk_get() will be
called and a struct clk will be instantiated for device0 (called in
the figure clk 1). A link between device0 and the new clk 1 instance of
periph0 will be created and stored in the clk->consumer_link entry.

   ++++
   ||||
   ||||
   |   xtal0 core   ||   xtal1 core   |
   ||||
   ||||
   +---^^---++---^^---+
   ||||
   ||||
   ++++
   ||||
   |   xtal0 clk||   xtal1 clk|
   ||||
   +++---^+
 |
 |
  +--+
  |   ->parent_clk_link
  |
  ++
  ||
  ||
  |  periph0 core  |
  |<-+
  |<-|
  +---^^---+||
  ||||
  ||||
  ++++
  |

[PATCH v4 4/4] clk: mvebu: armada-37xx-xtal: fill the device entry when registering the clock

[Miquel Raynal]

So far the clk_hw_register_fixed_factor() call was not providing any
device structure. While doing so is harmless for regular use, the
missing device structure may be a problem for suspend to RAM support.

Since, device links have been added to clocks, links created during
probe will enforce the suspend/resume orders. When the device is
missing during the registration, no link can be established, hence the
order between parent and child clocks are not enforced.

Adding the device structure here will create a link between the XTAL
clock (this one) and the four TBG clocks that are derived from it.

Signed-off-by: Miquel Raynal 
---
 drivers/clk/mvebu/armada-37xx-xtal.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/mvebu/armada-37xx-xtal.c 
b/drivers/clk/mvebu/armada-37xx-xtal.c
index e9e306d4e9af..0e74bcd83d1a 100644
--- a/drivers/clk/mvebu/armada-37xx-xtal.c
+++ b/drivers/clk/mvebu/armada-37xx-xtal.c
@@ -57,7 +57,8 @@ static int armada_3700_xtal_clock_probe(struct 
platform_device *pdev)
rate = 2500;
 
of_property_read_string_index(np, "clock-output-names", 0, _name);
-   xtal_hw = clk_hw_register_fixed_rate(NULL, xtal_name, NULL, 0, rate);
+   xtal_hw = clk_hw_register_fixed_rate(>dev, xtal_name, NULL, 0,
+rate);
if (IS_ERR(xtal_hw))
return PTR_ERR(xtal_hw);
ret = of_clk_add_hw_provider(np, of_clk_hw_simple_get, xtal_hw);
-- 
2.19.1

[PATCH v4 1/4] clk: core: link consumer with clock driver

[Miquel Raynal]

One major concern when, for instance, suspending/resuming a platform
is to never access registers before the underlying clock has been
resumed, otherwise most of the time the kernel will just crash. One
solution is to use syscore operations when registering clock drivers
suspend/resume callbacks. One problem of using syscore_ops is that the
suspend/resume scheduling will depend on the order of the
registrations, which brings (unacceptable) randomness in the process.

A feature called device links has been introduced to handle such
situation. It creates dependencies between consumers and providers,
enforcing e.g. the suspend/resume order when needed. Such feature is
already in use for regulators.

Add device links support in the clock subsystem by creating/deleting
the links at get/put time.

Example of a boot (ESPRESSObin, A3700 SoC) with devices linked to clocks:

marvell-armada-3700-tbg-clock d0013200.tbg: Linked as a consumer to 
d0013800.pinctrl:xtal-clk
marvell-armada-3700-tbg-clock d0013200.tbg: Dropping the link to 
d0013800.pinctrl:xtal-clk
marvell-armada-3700-tbg-clock d0013200.tbg: Linked as a consumer to 
d0013800.pinctrl:xtal-clk
marvell-armada-3700-periph-clock d0013000.nb-periph-clk: Linked as a consumer 
to d0013200.tbg
marvell-armada-3700-periph-clock d0013000.nb-periph-clk: Linked as a consumer 
to d0013800.pinctrl:xtal-clk
marvell-armada-3700-periph-clock d0018000.sb-periph-clk: Linked as a consumer 
to d0013200.tbg
mvneta d003.ethernet: Linked as a consumer to d0018000.sb-periph-clk
xhci-hcd d0058000.usb: Linked as a consumer to d0018000.sb-periph-clk
xenon-sdhci d00d.sdhci: Linked as a consumer to d0013000.nb-periph-clk
xenon-sdhci d00d.sdhci: Dropping the link to d0013000.nb-periph-clk
mvebu-uart d0012000.serial: Linked as a consumer to d0013800.pinctrl:xtal-clk
advk-pcie d007.pcie: Linked as a consumer to d0018000.sb-periph-clk
xenon-sdhci d00d.sdhci: Linked as a consumer to d0013000.nb-periph-clk
xenon-sdhci d00d.sdhci: Linked as a consumer to regulator.1
cpu cpu0: Linked as a consumer to d0013000.nb-periph-clk
cpu cpu0: Dropping the link to d0013000.nb-periph-clk
cpu cpu0: Linked as a consumer to d0013000.nb-periph-clk

Signed-off-by: Miquel Raynal 
---
 drivers/clk/clk.c | 50 ++-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index e1449db544c7..5c36ff52cb72 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -78,6 +78,7 @@ struct clk_core {
struct hlist_node   debug_node;
 #endif
struct kref ref;
+   struct device_link  *parent_clk_link;
 };
 
 #define CREATE_TRACE_POINTS
@@ -92,6 +93,7 @@ struct clk {
unsigned long max_rate;
unsigned int exclusive_count;
struct hlist_node clks_node;
+   struct device_link *consumer_link;
 };
 
 /***   runtime pm  ***/
@@ -276,6 +278,35 @@ struct clk_hw *clk_hw_get_parent(const struct clk_hw *hw)
 }
 EXPORT_SYMBOL_GPL(clk_hw_get_parent);
 
+static void clk_link_consumer(struct device *consumer, struct clk *clk)
+{
+   if (consumer && clk)
+   clk->consumer_link = device_link_add(consumer, clk->core->dev,
+DL_FLAG_STATELESS);
+}
+
+static void clk_unlink_consumer(struct clk *clk)
+{
+   if (clk && clk->consumer_link)
+   device_link_del(clk->consumer_link);
+}
+
+static void clk_link_hierarchy(struct clk_core *consumer,
+  struct clk_core *provider)
+{
+   if (consumer && provider)
+   consumer->parent_clk_link = device_link_add(consumer->dev,
+   provider->dev,
+   DL_FLAG_STATELESS);
+}
+
+static void clk_unlink_hierarchy(struct clk_core *consumer,
+struct clk_core *provider)
+{
+   if (consumer && provider && consumer->parent_clk_link)
+   device_link_del(consumer->parent_clk_link);
+}
+
 static struct clk_core *__clk_lookup_subtree(const char *name,
 struct clk_core *core)
 {
@@ -1599,6 +1630,9 @@ static void clk_reparent(struct clk_core *core, struct 
clk_core *new_parent)
 
hlist_del(>child_node);
 
+   if (core->parent)
+   clk_unlink_hierarchy(core, core->parent);
+
if (new_parent) {
bool becomes_orphan = new_parent->orphan;
 
@@ -1610,6 +1644,8 @@ static void clk_reparent(struct clk_core *core, struct 
clk_core *new_parent)
 
if (was_orphan != becomes_orphan)
clk_core_update_orphan_status(core, becomes_orphan);
+
+   clk_link_hierarchy(core, new_parent);
} else {
hlist_add_head(>child_node, _orphan_list);
if (!was_orphan)
@@ -2336,6 +2372,8 @@ __clk_init_parent(struct 

[PATCH v4 3/4] clk: mvebu: armada-37xx-tbg: fill the device entry when registering the clocks

[Miquel Raynal]

So far the clk_hw_register_fixed_factor() calls are not providing any
device structure. While doing so is harmless for regular use, the
missing device structure may be a problem for suspend to RAM support.

Since, device links have been added to clocks, links created during
probe will enforce the suspend/resume orders. When the device is
missing during the registration, no link can be established, hence the
order between parent and child clocks are not enforced.

Adding the device structure here will create a link between the 4 TBG
clocks (registered by this driver) and:
* their parent clock: XTAL,
* their child clocks: several 'periph' clock.

Signed-off-by: Miquel Raynal 
---
 drivers/clk/mvebu/armada-37xx-tbg.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/mvebu/armada-37xx-tbg.c 
b/drivers/clk/mvebu/armada-37xx-tbg.c
index 77b978c55ef6..da3a08e419d6 100644
--- a/drivers/clk/mvebu/armada-37xx-tbg.c
+++ b/drivers/clk/mvebu/armada-37xx-tbg.c
@@ -116,8 +116,10 @@ static int armada_3700_tbg_clock_probe(struct 
platform_device *pdev)
name = tbg[i].name;
mult = tbg_get_mult(reg, [i]);
div = tbg_get_div(reg, [i]);
-   hw_tbg_data->hws[i] = clk_hw_register_fixed_factor(NULL, name,
-   parent_name, 0, mult, div);
+   hw_tbg_data->hws[i] = clk_hw_register_fixed_factor(dev, name,
+  parent_name,
+  0, mult,
+  div);
if (IS_ERR(hw_tbg_data->hws[i]))
dev_err(dev, "Can't register TBG clock %s\n", name);
}
-- 
2.19.1

[PATCH v4 2/4] clk: mvebu: armada-37xx-tbg: fix error message

[Miquel Raynal]

The error message should state that the driver failed to get the
parent clock, not the opposite.

Signed-off-by: Miquel Raynal 
---
 drivers/clk/mvebu/armada-37xx-tbg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/mvebu/armada-37xx-tbg.c 
b/drivers/clk/mvebu/armada-37xx-tbg.c
index ee272d4d8c24..77b978c55ef6 100644
--- a/drivers/clk/mvebu/armada-37xx-tbg.c
+++ b/drivers/clk/mvebu/armada-37xx-tbg.c
@@ -98,7 +98,7 @@ static int armada_3700_tbg_clock_probe(struct platform_device 
*pdev)
 
parent = clk_get(dev, NULL);
if (IS_ERR(parent)) {
-   dev_err(dev, "Could get the clock parent\n");
+   dev_err(dev, "Could not get the clock parent\n");
return -EINVAL;
}
parent_name = __clk_get_name(parent);
-- 
2.19.1

Applied "regulator: Fix trivial language typos" to the regulator tree

[Mark Brown]

The patch

   regulator: Fix trivial language typos

has been applied to the regulator tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 48f1b4efd67c922eff113f247533cbe175b1491e Mon Sep 17 00:00:00 2001
From: Krzysztof Kozlowski 
Date: Tue, 8 Jan 2019 13:12:33 +0100
Subject: [PATCH] regulator: Fix trivial language typos

Fix few trivial language typos in core and drivers.

Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Mark Brown 
---
 .../devicetree/bindings/regulator/pfuze100.txt   |  2 +-
 drivers/regulator/Kconfig|  8 
 drivers/regulator/core.c | 16 
 drivers/regulator/lp8755.c   |  4 ++--
 drivers/regulator/of_regulator.c |  4 ++--
 5 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.txt 
b/Documentation/devicetree/bindings/regulator/pfuze100.txt
index f9be1acf891c..4d3b12b92cb3 100644
--- a/Documentation/devicetree/bindings/regulator/pfuze100.txt
+++ b/Documentation/devicetree/bindings/regulator/pfuze100.txt
@@ -8,7 +8,7 @@ Optional properties:
 - fsl,pfuze-support-disable-sw: Boolean, if present disable all unused switch
   regulators to save power consumption. Attention, ensure that all important
   regulators (e.g. DDR ref, DDR supply) has set the "regulator-always-on"
-  property. If not present, the switched regualtors are always on and can't be
+  property. If not present, the switched regulators are always on and can't be
   disabled. This binding is a workaround to keep backward compatibility with
   old dtb's which rely on the fact that the switched regulators are always on
   and don't mark them explicit as "regulator-always-on".
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index ee60a222f5eb..7fc1f88e27e7 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -484,7 +484,7 @@ config REGULATOR_MAX8925
tristate "Maxim MAX8925 Power Management IC"
depends on MFD_MAX8925
help
- Say y here to support the voltage regulaltor of Maxim MAX8925 PMIC.
+ Say y here to support the voltage regulator of Maxim MAX8925 PMIC.
 
 config REGULATOR_MAX8952
tristate "Maxim MAX8952 Power Management IC"
@@ -501,7 +501,7 @@ config REGULATOR_MAX8973
select REGMAP_I2C
help
  The MAXIM MAX8973 high-efficiency. three phase, DC-DC step-down
- switching regulator delievers up to 9A of output current. Each
+ switching regulator delivers up to 9A of output current. Each
  phase operates at a 2MHz fixed frequency with a 120 deg shift
  from the adjacent phase, allowing the use of small magnetic component.
 
@@ -646,7 +646,7 @@ config REGULATOR_PCF50633
tristate "NXP PCF50633 regulator driver"
depends on MFD_PCF50633
help
-Say Y here to support the voltage regulators and convertors
+Say Y here to support the voltage regulators and converters
 on PCF50633
 
 config REGULATOR_PFUZE100
@@ -924,7 +924,7 @@ config REGULATOR_TPS65132
select REGMAP_I2C
help
  This driver supports TPS65132 single inductor - dual output
- power supply specifcally designed for display panels.
+ power supply specifically designed for display panels.
 
 config REGULATOR_TPS65217
tristate "TI TPS65217 Power regulators"
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index b9d7b45c7295..3f9d81b6e763 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -326,7 +326,7 @@ static int regulator_lock_recursive(struct regulator_dev 
*rdev,
  * @rdev:  regulator source
  * @ww_ctx:w/w mutex acquire context
  *
- * Unlock all regulators related with rdev by coupling or suppling.
+ * Unlock all regulators related with rdev by coupling or supplying.
  */
 static void regulator_unlock_dependent(struct regulator_dev *rdev,
   struct ww_acquire_ctx *ww_ctx)
@@ -341,7 +341,7 @@ static void regulator_unlock_dependent(struct regulator_dev 
*rdev,
  * @ww_ctx:  

Applied "ASoC: ADAU7002: Add optional delay before start of capture" to the asoc tree

[Mark Brown]

The patch

   ASoC: ADAU7002: Add optional delay before start of capture

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 7b57085a33ce55e28616f04fd9877ba2ca7e79de Mon Sep 17 00:00:00 2001
From: "Agrawal, Akshu" 
Date: Tue, 8 Jan 2019 10:24:40 +
Subject: [PATCH] ASoC: ADAU7002: Add optional delay before start of capture

On capture through some of dmic we observe a glitch at the
start of record. This is because we start capturing even before
dmic is ready to send out data.
The optional delay will be applied after enabling the mic.

Signed-off-by: Akshu Agrawal 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/adau7002.c | 45 +
 1 file changed, 45 insertions(+)

diff --git a/sound/soc/codecs/adau7002.c b/sound/soc/codecs/adau7002.c
index fdff86878287..a8deb37fc78a 100644
--- a/sound/soc/codecs/adau7002.c
+++ b/sound/soc/codecs/adau7002.c
@@ -8,6 +8,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -15,12 +16,55 @@
 
 #include 
 
+struct adau7002_priv {
+   int wakeup_delay;
+};
+
+static int adau7002_aif_event(struct snd_soc_dapm_widget *w,
+ struct snd_kcontrol *kcontrol, int event)
+{
+   struct snd_soc_component *component =
+   snd_soc_dapm_to_component(w->dapm);
+   struct adau7002_priv *adau7002 =
+   snd_soc_component_get_drvdata(component);
+
+   switch (event) {
+   case SND_SOC_DAPM_POST_PMU:
+   if (adau7002->wakeup_delay)
+   msleep(adau7002->wakeup_delay);
+   break;
+   }
+
+   return 0;
+}
+
+static int adau7002_component_probe(struct snd_soc_component *component)
+{
+   struct adau7002_priv *adau7002;
+
+   adau7002 = devm_kzalloc(component->dev, sizeof(*adau7002),
+   GFP_KERNEL);
+   if (!adau7002)
+   return -ENOMEM;
+
+   device_property_read_u32(component->dev, "wakeup-delay-ms",
+>wakeup_delay);
+
+   snd_soc_component_set_drvdata(component, adau7002);
+
+   return 0;
+}
+
 static const struct snd_soc_dapm_widget adau7002_widgets[] = {
+   SND_SOC_DAPM_AIF_OUT_E("ADAU AIF", "Capture", 0,
+  SND_SOC_NOPM, 0, 0, adau7002_aif_event,
+  SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_POST_PMD),
SND_SOC_DAPM_INPUT("PDM_DAT"),
SND_SOC_DAPM_REGULATOR_SUPPLY("IOVDD", 0, 0),
 };
 
 static const struct snd_soc_dapm_route adau7002_routes[] = {
+   { "ADAU AIF", NULL, "PDM_DAT"},
{ "Capture", NULL, "PDM_DAT" },
{ "Capture", NULL, "IOVDD" },
 };
@@ -40,6 +84,7 @@ static struct snd_soc_dai_driver adau7002_dai = {
 };
 
 static const struct snd_soc_component_driver adau7002_component_driver = {
+   .probe  = adau7002_component_probe,
.dapm_widgets   = adau7002_widgets,
.num_dapm_widgets   = ARRAY_SIZE(adau7002_widgets),
.dapm_routes= adau7002_routes,
-- 
2.20.1

Re: Linux 5.0-rc1 (test results)

[Guo Ren]

Thx Michal,

On Tue, Jan 08, 2019 at 04:40:31PM +0100, Michal Hocko wrote:
> On Tue 08-01-19 17:51:07, Guo Ren wrote:
> [...]
> > static inline pte_t *pte_alloc_one_kernel(struct mm_struct *mm)
> > {
> > pte_t *pte;
> > unsigned long i;
> > 
> > pte = (pte_t *) __get_free_page(GFP_KERNEL | __GFP_RETRY_MAYFAIL);
> >  ^^^
> >  It's necessary ?
> >  x86 & arm don't use
> >  it.
> > if (!pte)
> > return NULL;
> 
> That depends on whether you want OOM killer to be triggered for these
> allocations. If you add the flag then the allocation bails out with a
> failure rather than kill an oom victim.

Yes, in page_alloc.c: 
if (gfp_mask & __GFP_RETRY_MAYFAIL)
goto out;
...
if (out_of_memory() || WARN_ON_ONCE(gfp_mask & __GFP_NOFAIL)) {
^ OOM kill victim
...
if (gfp_mask & __GFP_NOFAIL)
page = __alloc_pages_cpuset_fallback(gfp_mask, order,
ALLOC_NO_WATERMARKS, ac);
}

Seems it could affect the behavior of the system which is out of memory.
OOM killer could help to get_page for current. So keep the same as x86 &
arm here. I'll remove __GFP_RETRY_MAYFAIL in patch.

Best Regards
 Guo Ren

[PATCH] sparc: use struct_size() in kzalloc()

[Gustavo A. R. Silva]

One of the more common cases of allocation size calculations is finding the
size of a structure that has a zero-sized array at the end, along with memory
for some number of elements for that array. For example:

struct foo {
int stuff;
void *entry[];
};

instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);

Instead of leaving these open-coded and prone to type mistakes, we can now
use the new struct_size() helper:

instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);

This code was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 arch/sparc/kernel/cpumap.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/sparc/kernel/cpumap.c b/arch/sparc/kernel/cpumap.c
index d1d52822603d..1cb62bfeaa1f 100644
--- a/arch/sparc/kernel/cpumap.c
+++ b/arch/sparc/kernel/cpumap.c
@@ -194,8 +194,7 @@ static struct cpuinfo_tree *build_cpuinfo_tree(void)
 
n = enumerate_cpuinfo_nodes(tmp_level);
 
-   new_tree = kzalloc(sizeof(struct cpuinfo_tree) +
-  (sizeof(struct cpuinfo_node) * n), GFP_ATOMIC);
+   new_tree = kzalloc(struct_size(new_tree, nodes, n), GFP_ATOMIC);
if (!new_tree)
return NULL;
 
-- 
2.20.1

Re: [PATCH v3 1/3] mfd: cros_ec: Add commands to control codec

[Mark Brown]

On Tue, Jan 08, 2019 at 09:54:50AM +, Lee Jones wrote:
> On Mon, 07 Jan 2019, Mark Brown wrote:

> > Is there a tag I can merge?

> Afraid not, but I reserve the right to rebase my tree, so if you want
> one, you can have one.

Yes, please - that'd be most helpful!


signature.asc
Description: PGP signature

Re: [PATCH] usb: gadget: musb: fix short isoc packets with inventra dma for pandaboard es

[Bin Liu]

On Mon, Jan 07, 2019 at 11:45:24PM -0500, Paul Elder wrote:
> Hi Bin,
> 
> On Mon, Jan 07, 2019 at 01:11:57PM -0600, Bin Liu wrote:
> > Hi Paul,
> > 
> > Sorry for the delay on reviewing it.
> 
> Thanks for the review.
> 
> > For the subject, can you please use
> > 
> > usb: musb: gadget: fix short isoc packets with inventra dma
> 
> ack
> 
> > On Tue, Oct 09, 2018 at 02:32:20AM -0400, Paul Elder wrote:
> > > Handling short packets (length < max packet size) in the Inventra DMA
> > > engine in the MUSB driver causes the MUSB DMA controller to hang. An
> > > example of a problem that is caused by this problem is when streaming
> > > video out of a UVC gadget, only the first video frame is transferred.
> > > 
> > > For short packets (mode-0 or mode-1 DMA), MUSB_TXCSR_TXPKTRDY must be
> > > set manually by the driver. This was previously done in musb_g_tx
> > > (musb_gadget.c), but incorrectly (all csr flags were cleared, and only
> > > MUSB_TXCSR_MODE and MUSB_TXCSR_TXPKTRDY). Fixing that problem allows
> > > some requests to be transferred correctly, but multiple requests were
> > > often put together in one USB packet, and caused problems if the packet
> > > size was not a multiple of 4.
> > > 
> > > Instead, MUSB_TXCSR_TXPKTRDY is set in dma_controller_irq (musbhsdma.c),
> > > just like host mode transfers, then musb_g_tx forces the packet to be
> > > flushed, by setting MUSB_TXCSR_FLUSHFIFO.

This should be reworded, since we don't set MUSB_TXCSR_FLUSHFIFO in the
code.

> > > 
> > > This topic was originally tackled by Nicolas Boichat [0] [1] and is 
> > > discussed
> > 
> > this line is longer than 75 chars.
> 
> ack
> 
> > > further at [2] as part of his GSoC project [3].
> > > 
> > > [0] 
> > > https://groups.google.com/forum/?hl=en#!topic/beagleboard-gsoc/k8Azwfp75CU
> > > [1] 
> > > https://gitorious.org/beagleboard-usbsniffer/beagleboard-usbsniffer-kernel/commit/b0be3b6cc195ba732189b04f1d43ec843c3e54c9?p=beagleboard-usbsniffer:beagleboard-usbsniffer-kernel.git;a=patch;h=b0be3b6cc195ba732189b04f1d43ec843c3e54c9
> > > [2] 
> > > http://beagleboard-usbsniffer.blogspot.com/2010/07/musb-isochronous-transfers-fixed.html
> > > [3] http://elinux.org/BeagleBoard/GSoC/USBSniffer
> > > 
> > > I have forward-ported this patch from 2.6.34 to 4.19-rc1.
> > 
> > this line is irrelevant to the commit message, please move it down to
> > under '---'.
> 
> ack
> 
> > > 
> > > Signed-off-by: Paul Elder 
> > > ---
> > >  drivers/usb/musb/musb_gadget.c | 21 ++---
> > >  drivers/usb/musb/musbhsdma.c   | 21 +++--
> > >  2 files changed, 25 insertions(+), 17 deletions(-)
> > > 
> > > diff --git a/drivers/usb/musb/musb_gadget.c 
> > > b/drivers/usb/musb/musb_gadget.c
> > > index eae8b1b1b45b..d3f33f449445 100644
> > > --- a/drivers/usb/musb/musb_gadget.c
> > > +++ b/drivers/usb/musb/musb_gadget.c
> > > @@ -479,11 +479,16 @@ void musb_g_tx(struct musb *musb, u8 epnum)
> > >   && (request->actual == request->length))
> > >   short_packet = true;
> > >  
> > > - if ((musb_dma_inventra(musb) || musb_dma_ux500(musb)) &&
> > > - (is_dma && (!dma->desired_mode ||
> > > - (request->actual &
> > > - (musb_ep->packet_sz - 1)
> > > - short_packet = true;
> > > + if (is_dma && (musb_dma_inventra(musb) || 
> > > musb_dma_ux500(musb))) {
> > 
> > more than 80 chars.
> >
> > > + if (!dma->desired_mode ||
> > 
> > I understand you forward-port Nicolas' patch, but do you have a specific
> > readon to re-write this 'if' condition? I'd like to see minimum code
> > change in bug fixes,
> >
> > > + request->actual % musb_ep->packet_sz) {
> > 
> > but I like this version though, easier to read.
> > 
> > > + musb_dbg(musb, "%s Flushing (FIFO) EP : KPB\n",
> > 
> > what is 'KPB'? the message could be more meaningful?
> > 
> > > + musb_ep->end_point.name);
> > > + musb_writew(epio, MUSB_TXCSR,
> > > + csr | MUSB_TXCSR_FLUSHFIFO);
> > 
> > What if without this line? The short packet doesn't send out?  setting
> > TXSCR_TXPKTRDY in the dma driver is not sufficient?  TXSCR_FLUSHFIFO is
> > only used for aborting cases.
> 
> I just tested this and you are right, it does work without this line.
> Since this is the only significant line in this very complex if block,
> I'll just remove this entire block too.
> 
> > > + return;
> > > + }
> > > + }
> > >  
> > >   if (short_packet) {
> > >   /*
> > > @@ -493,8 +498,10 @@ void musb_g_tx(struct musb *musb, u8 epnum)
> > >   if (csr & MUSB_TXCSR_TXPKTRDY)
> > >   return;
> > >  
> > > - musb_writew(epio, MUSB_TXCSR, 

Re: [Qemu-devel][PATCH 3/4] Add hepler functions for CPUID xsave area size calculation.

[Christophe de Dinechin]

Typo in subject line (helper)

> On 26 Dec 2018, at 09:25, Yang Weijiang  wrote:
> 
> These functions are called when return CPUID xsave area
> size information.
> 
> Signed-off-by: Zhang Yi 
> Signed-off-by: Yang Weijiang 
> ---
> target/i386/cpu.c | 26 +-
> 1 file changed, 25 insertions(+), 1 deletion(-)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 3630c688d6..cf4f2798dc 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -1281,12 +1281,34 @@ static inline bool accel_uses_host_cpuid(void)
> return kvm_enabled() || hvf_enabled();
> }
> 
> +static uint32_t xsave_area_size_compat(uint64_t mask)

Just curious, why “compat”?

> +{
> +int i;
> +uint64_t ret = 0;
> +uint32_t offset;
> +
> +for (i = 0; i < ARRAY_SIZE(x86_ext_save_areas); i++) {
> +const ExtSaveArea *esa = _ext_save_areas[i];
> +offset = i > 1 ? ret : esa->offset;

What about a named constant instead of ‘1’?

(note that a loop around line 4657 starts at 2, so I guess it’s OK to use 1 
here, or at least >= 2 ;-)


> +if ((mask >> i) & 1) {
> +ret = MAX(ret, offset + esa->size);
> +}
> +}
> +return ret;
> +}
> +
> static inline uint64_t x86_cpu_xsave_components(X86CPU *cpu)
> {
> return ((uint64_t)cpu->env.features[FEAT_XSAVE_COMP_HI]) << 32 |
>cpu->env.features[FEAT_XSAVE_COMP_LO];
> }
> 
> +static inline uint64_t x86_cpu_xsave_sv_components(X86CPU *cpu)
> +{
> +return ((uint64_t)cpu->env.features[FEAT_XSAVE_SV_HI]) << 32 |
> +   cpu->env.features[FEAT_XSAVE_SV_LO];
> +}
> +
> const char *get_register_name_32(unsigned int reg)
> {
> if (reg >= CPU_NB_REGS32) {
> @@ -4913,8 +4935,10 @@ static void x86_cpu_enable_xsave_components(X86CPU 
> *cpu)
> }
> }
> 
> -env->features[FEAT_XSAVE_COMP_LO] = mask;
> +env->features[FEAT_XSAVE_COMP_LO] = mask & CPUID_XSTATE_USER_MASK;
> env->features[FEAT_XSAVE_COMP_HI] = mask >> 32;
> +env->features[FEAT_XSAVE_SV_LO] = mask & CPUID_XSTATE_KERNEL_MASK;
> +env->features[FEAT_XSAVE_SV_HI] = mask >> 32;
> }
> 
> /* Steps involved on loading and filtering CPUID data
> -- 
> 2.17.1
> 

Re: [PATCH 1/3] usb: kconfig: remove dependency FSL_SOC for ehci fsl driver

[Alan Stern]

On Tue, 8 Jan 2019, Ran Wang wrote:

> From: Rajesh Bhagat 
> 
> CONFIG_USB_EHCI_FSL is not dependent on FSL_SOC, it can be built on
> non-PPC platforms.
> 
> Signed-off-by: Rajesh Bhagat 
> Signed-off-by: Ran Wang 
> ---
>  drivers/usb/host/Kconfig |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 16758b1..53cbc0c 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -179,8 +179,8 @@ config XPS_USB_HCD_XILINX
>   devices only.
>  
>  config USB_EHCI_FSL
> - tristate "Support for Freescale PPC on-chip EHCI USB controller"
> - depends on FSL_SOC
> + tristate "Support for Freescale on-chip EHCI USB controller"
> + depends on USB_EHCI_HCD

This line is not needed.  The entire entry lies within an "if 
USB_EHCI_HCD" block.

Alan Stern

>   select USB_EHCI_ROOT_HUB_TT
>   ---help---
> Variation of ARC USB block used in some Freescale chips.
> 

[PATCH 03/10] platform/chrome: cros_ec_sysfs: remove unused includes

[Enric Balletbo i Serra]

None of these are required at the moment.

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/platform/chrome/cros_ec_sysfs.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/platform/chrome/cros_ec_sysfs.c 
b/drivers/platform/chrome/cros_ec_sysfs.c
index 0ff5aa30c070..3d1c1a7415a8 100644
--- a/drivers/platform/chrome/cros_ec_sysfs.c
+++ b/drivers/platform/chrome/cros_ec_sysfs.c
@@ -20,19 +20,12 @@
 #define pr_fmt(fmt) "cros_ec_sysfs: " fmt
 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
-#include 
-#include 
-#include 
 
 #define DRV_NAME "cros-ec-sysfs"
 
-- 
2.20.1

[PATCH 02/10] platform/chrome: cros_ec_lightbar: remove unused includes

[Enric Balletbo i Serra]

None of these are required at the moment.

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/platform/chrome/cros_ec_lightbar.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/platform/chrome/cros_ec_lightbar.c 
b/drivers/platform/chrome/cros_ec_lightbar.c
index c3e4e6e5211d..cc2f386a59f0 100644
--- a/drivers/platform/chrome/cros_ec_lightbar.c
+++ b/drivers/platform/chrome/cros_ec_lightbar.c
@@ -20,17 +20,10 @@
 #define pr_fmt(fmt) "cros_ec_lightbar: " fmt
 
 #include 
-#include 
-#include 
 #include 
-#include 
 #include 
-#include 
 #include 
 #include 
-#include 
-#include 
-#include 
 #include 
 
 #define DRV_NAME "cros-ec-lightbar"
-- 
2.20.1

[PATCH 04/10] platform/chrome: cros_ec_vbc: remove unused includes

[Enric Balletbo i Serra]

None of these are required at the moment.

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/platform/chrome/cros_ec_vbc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/platform/chrome/cros_ec_vbc.c 
b/drivers/platform/chrome/cros_ec_vbc.c
index af9bfe6f385c..86903bc31b27 100644
--- a/drivers/platform/chrome/cros_ec_vbc.c
+++ b/drivers/platform/chrome/cros_ec_vbc.c
@@ -18,10 +18,8 @@
  * GNU General Public License for more details.
  */
 
-#include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
-- 
2.20.1

Re: [PATCH 0/2] /proc/stat: Reduce irqs counting performance overhead

[Michal Hocko]

On Tue 08-01-19 13:04:22, Dave Chinner wrote:
> On Mon, Jan 07, 2019 at 05:41:39PM -0500, Waiman Long wrote:
> > On 01/07/2019 05:32 PM, Dave Chinner wrote:
> > > On Mon, Jan 07, 2019 at 10:12:56AM -0500, Waiman Long wrote:
> > >> As newer systems have more and more IRQs and CPUs available in their
> > >> system, the performance of reading /proc/stat frequently is getting
> > >> worse and worse.
> > > Because the "roll-your-own" per-cpu counter implementaiton has been
> > > optimised for low possible addition overhead on the premise that
> > > summing the counters is rare and isn't a performance issue. This
> > > patchset is a direct indication that this "summing is rare and can
> > > be slow" premise is now invalid.
> > >
> > > We have percpu counter infrastructure that trades off a small amount
> > > of addition overhead for zero-cost reading of the counter value.
> > > i.e. why not just convert this whole mess to percpu_counters and
> > > then just use percpu_counter_read_positive()? Then we just don't
> > > care how often userspace reads the /proc file because there is no
> > > summing involved at all...
> > >
> > > Cheers,
> > >
> > > Dave.
> > 
> > Yes, percpu_counter_read_positive() is cheap. However, you still need to
> > pay the price somewhere. In the case of percpu_counter, the update is
> > more expensive.
> 
> Ummm, that's exactly what I just said. It's a percpu counter that
> solves the "sum is expensive and frequent" problem, just like you
> are encountering here. I do not need basic scalability algorithms
> explained to me.
> 
> > I would say the percentage of applications that will hit this problem is
> > small. But for them, this problem has some significant performance overhead.
> 
> Well, duh!
> 
> What I was suggesting is that you change the per-cpu counter
> implementation to the /generic infrastructure/ that solves this
> problem, and then determine if the extra update overhead is at all
> measurable. If you can't measure any difference in update overhead,
> then slapping complexity on the existing counter to attempt to
> mitigate the summing overhead is the wrong solution.
> 
> Indeed, it may be that you need o use a custom batch scaling curve
> for the generic per-cpu coutner infrastructure to mitigate the
> update overhead, but the fact is we already have generic
> infrastructure that solves your problem and so the solution should
> be "use the generic infrastructure" until it can be proven not to
> work.
> 
> i.e. prove the generic infrastructure is not fit for purpose and
> cannot be improved sufficiently to work for this use case before
> implementing a complex, one-off snowflake counter implementation...

Completely agreed! Apart from that I find that conversion to a generic
infrastructure worth even if that doesn't solve the problem at hands
completely. If for no other reasons then the sheer code removal as kstat
is not really used for anything apart from this accounting AFAIR. The
less ad-hoc code we have the better IMHO.

And to the underlying problem. Some proc files do not scale on large
machines. Maybe it is time to explain that to application writers that
if they are collecting data too agressively then it won't scale. We can
only do this much. Lying about numbers by hiding updates is, well,
lying and won't solve the underlying problem. 
-- 
Michal Hocko
SUSE Labs

[PATCH 05/10] platform/chrome: cros_ec_lightbar: remove pr_fmt() define

[Enric Balletbo i Serra]

This driver no longer has any pr_{level} messages. Remove the pr_fmt().

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/platform/chrome/cros_ec_lightbar.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/platform/chrome/cros_ec_lightbar.c 
b/drivers/platform/chrome/cros_ec_lightbar.c
index cc2f386a59f0..4211a26587d3 100644
--- a/drivers/platform/chrome/cros_ec_lightbar.c
+++ b/drivers/platform/chrome/cros_ec_lightbar.c
@@ -17,8 +17,6 @@
  * along with this program. If not, see .
  */
 
-#define pr_fmt(fmt) "cros_ec_lightbar: " fmt
-
 #include 
 #include 
 #include 
-- 
2.20.1

[PATCH 06/10] platform/chrome: cros_ec_sysfs: remove pr_fmt() define

[Enric Balletbo i Serra]

This driver no longer has any pr_{level} messages. Remove the pr_fmt().

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/platform/chrome/cros_ec_sysfs.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/platform/chrome/cros_ec_sysfs.c 
b/drivers/platform/chrome/cros_ec_sysfs.c
index 3d1c1a7415a8..c502c0f52092 100644
--- a/drivers/platform/chrome/cros_ec_sysfs.c
+++ b/drivers/platform/chrome/cros_ec_sysfs.c
@@ -17,8 +17,6 @@
  * along with this program. If not, see .
  */
 
-#define pr_fmt(fmt) "cros_ec_sysfs: " fmt
-
 #include 
 #include 
 #include 
-- 
2.20.1

[PATCH 10/10] platform/chrome: cros_ec_vbc: switch to SPDX identifier

[Enric Balletbo i Serra]

Adopt the SPDX license identifier headers to ease license compliance
management.

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/platform/chrome/cros_ec_vbc.c | 24 +---
 1 file changed, 5 insertions(+), 19 deletions(-)

diff --git a/drivers/platform/chrome/cros_ec_vbc.c 
b/drivers/platform/chrome/cros_ec_vbc.c
index 86903bc31b27..63f451f85d8d 100644
--- a/drivers/platform/chrome/cros_ec_vbc.c
+++ b/drivers/platform/chrome/cros_ec_vbc.c
@@ -1,22 +1,8 @@
-/*
- * cros_ec_vbc - Expose the vboot context nvram to userspace
- *
- * Copyright (C) 2015 Collabora Ltd.
- *
- * based on vendor driver,
- *
- * Copyright (C) 2012 The Chromium OS Authors
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- */
+// SPDX-License-Identifier: GPL-2.0+
+// Expose the vboot context nvram to userspace
+//
+// Copyright (C) 2012 Google, Inc.
+// Copyright (C) 2015 Collabora Ltd.
 
 #include 
 #include 
-- 
2.20.1

[PATCH 09/10] platform/chrome: cros_ec_sysfs: switch to SPDX identifier

[Enric Balletbo i Serra]

Adopt the SPDX license identifier headers to ease license compliance
management.

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/platform/chrome/cros_ec_sysfs.c | 22 --
 1 file changed, 4 insertions(+), 18 deletions(-)

diff --git a/drivers/platform/chrome/cros_ec_sysfs.c 
b/drivers/platform/chrome/cros_ec_sysfs.c
index c502c0f52092..c2dd253567ec 100644
--- a/drivers/platform/chrome/cros_ec_sysfs.c
+++ b/drivers/platform/chrome/cros_ec_sysfs.c
@@ -1,21 +1,7 @@
-/*
- * cros_ec_sysfs - expose the Chrome OS EC through sysfs
- *
- * Copyright (C) 2014 Google, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program. If not, see .
- */
+// SPDX-License-Identifier: GPL-2.0+
+// Expose the ChromeOS EC through sysfs
+//
+// Copyright (C) 2014 Google, Inc.
 
 #include 
 #include 
-- 
2.20.1

[PATCH 08/10] platform/chrome: cros_ec_lightbar: switch to SPDX identifier

[Enric Balletbo i Serra]

Adopt the SPDX license identifier headers to ease license compliance
management.

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/platform/chrome/cros_ec_lightbar.c | 22 --
 1 file changed, 4 insertions(+), 18 deletions(-)

diff --git a/drivers/platform/chrome/cros_ec_lightbar.c 
b/drivers/platform/chrome/cros_ec_lightbar.c
index 4211a26587d3..596b899e5508 100644
--- a/drivers/platform/chrome/cros_ec_lightbar.c
+++ b/drivers/platform/chrome/cros_ec_lightbar.c
@@ -1,21 +1,7 @@
-/*
- * cros_ec_lightbar - expose the Chromebook Pixel lightbar to userspace
- *
- * Copyright (C) 2014 Google, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program. If not, see .
- */
+// SPDX-License-Identifier: GPL-2.0+
+// Expose the Chromebook Pixel lightbar to userspace
+//
+// Copyright (C) 2014 Google, Inc.
 
 #include 
 #include 
-- 
2.20.1

[PATCH 07/10] platform/chrome: cros_ec_debugfs: switch to SPDX identifier

[Enric Balletbo i Serra]

Adopt the SPDX license identifier headers to ease license compliance
management.

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/platform/chrome/cros_ec_debugfs.c | 22 --
 1 file changed, 4 insertions(+), 18 deletions(-)

diff --git a/drivers/platform/chrome/cros_ec_debugfs.c 
b/drivers/platform/chrome/cros_ec_debugfs.c
index 5e0039509368..204738ff6338 100644
--- a/drivers/platform/chrome/cros_ec_debugfs.c
+++ b/drivers/platform/chrome/cros_ec_debugfs.c
@@ -1,21 +1,7 @@
-/*
- * cros_ec_debugfs - debug logs for Chrome OS EC
- *
- * Copyright 2015 Google, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program. If not, see .
- */
+// SPDX-License-Identifier: GPL-2.0+
+// Debug logs for the ChromeOS EC
+//
+// Copyright (C) 2015 Google, Inc.
 
 #include 
 #include 
-- 
2.20.1

[PATCH 01/10] platform/chrome: cros_ec_debugfs: remove unused includes

[Enric Balletbo i Serra]

None of these are required at the moment.

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/platform/chrome/cros_ec_debugfs.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/platform/chrome/cros_ec_debugfs.c 
b/drivers/platform/chrome/cros_ec_debugfs.c
index 6cacac53dfce..5e0039509368 100644
--- a/drivers/platform/chrome/cros_ec_debugfs.c
+++ b/drivers/platform/chrome/cros_ec_debugfs.c
@@ -19,17 +19,12 @@
 
 #include 
 #include 
-#include 
-#include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
-#include 
 
 #define DRV_NAME "cros-ec-debugfs"
 
-- 
2.20.1

[PATCH 00/10] platform/chrome: cros_ec: remove unused includes and switch to SPDX

[Enric Balletbo i Serra]

Hi,

After the patchset to move cros_ec sysfs attributes to its own drivers
[1], I'd like to do some cleanup and switch to the SPDX license on these
files. This patchset applies on top of [1] and can go through the
platform-chrome repository once [1] is applied.

Best regards,
  Enric

[1] https://lkml.org/lkml/2018/12/12/679

Enric Balletbo i Serra (10):
  platform/chrome: cros_ec_debugfs: remove unused includes
  platform/chrome: cros_ec_lightbar: remove unused includes
  platform/chrome: cros_ec_sysfs: remove unused includes
  platform/chrome: cros_ec_vbc: remove unused includes
  platform/chrome: cros_ec_lightbar: remove pr_fmt() define
  platform/chrome: cros_ec_sysfs: remove pr_fmt() define
  platform/chrome: cros_ec_debugfs: switch to SPDX identifier
  platform/chrome: cros_ec_lightbar: switch to SPDX identifier
  platform/chrome: cros_ec_sysfs: switch to SPDX identifier
  platform/chrome: cros_ec_vbc: switch to SPDX identifier

 drivers/platform/chrome/cros_ec_debugfs.c  | 27 +++
 drivers/platform/chrome/cros_ec_lightbar.c | 31 +++---
 drivers/platform/chrome/cros_ec_sysfs.c| 31 +++---
 drivers/platform/chrome/cros_ec_vbc.c  | 28 +--
 4 files changed, 18 insertions(+), 99 deletions(-)

-- 
2.20.1

Re: [PATCH v2] ARM: dts: imx: Add Y Soft IOTA Draco, Hydra and Ursa boards

[Vokáč Michal]

On 8.1.2019 16:00, Vokáč Michal wrote:
> On 8.1.2019 15:56, Rob Herring wrote:
>> On Tue, Jan 8, 2019 at 5:43 AM Vokáč Michal  wrote:
>>>
>>> On 29.12.2018 00:25, Rob Herring wrote:
 On Tue, Dec 18, 2018 at 02:42:11PM +, Vokáč Michal wrote:
> These are i.MX6S/DL based SBCs embedded in various Y Soft products.
> All share the same board design but have slightly different HW
> configuration.
>>
>> [...]
>>
> +/ {
> +model = "Y Soft IOTA Draco i.MX6Solo board";
> +compatible = "ysoft,imx6dl-yapp4-draco", "fsl,imx6dl";

 All compatible strings should be documented, not just SoC vendor boards.
>>>
>>> OK, I will add a Documentation/devicetree/bindings/arm/ysoft.yaml file for 
>>> that.
>>
>> Actually, it should go in fsl.yaml. The file for every board vendor is
>> gone. i.MX was pretty much the only platform doing that.
> 
> OK, I will do so. Thank you.

I am sorry for the noise Rob, but your "dt-bindings: arm: Convert FSL
board/soc bindings to json-schema" patch is not in mainline yet. So
there is no arm/fsl.yaml file to add my compatible strings into.

Now I do not know how to respin. Should I send this updated dts/dtsi
patch as usual and create another patch with the ysoft compatible
strings against your yaml-bindings-v2 branch, where the fsl.yaml file
exist? Or something else?

Thank you,
Michal

Re: [alsa-devel] [PATCH v1 3/3] ASoC: soc-core: fix platform name vs. of_node assignement

[Mark Brown]

On Tue, Jan 08, 2019 at 03:48:27PM +, Jon Hunter wrote:

> > Yes so this does workaround the problem. However, per my previous
> > comments, I would like to explore whether it is necessary to allocate
> > the platform link component or if it can be static.

> To be specific, the following also works ...

Thanks for working on this, that looks nice and simple - can you send
it as a real patch please (not reviewed properly yet but...)?


signature.asc
Description: PGP signature

Re: [PATCH 1/1] epoll: remove wrong assert that ep_poll_callback is always called with irqs off

[Roman Penyaev]

On 2019-01-08 16:16, Davidlohr Bueso wrote:

On 2019-01-08 04:42, Roman Penyaev wrote:

What we can do:

a) disable irqs if we are not in interrupt.
b) revert the patch completely.

David, is it really crucial in terms of performance to avoid double
local_irq_save() on Xen on this ep_poll_callback() hot path?


Note that such optimizations are also relevant for baremetal, ie: x86
PUSHF + POPF can be pretty expensive because of insn dependencies.



For example why not to do the following:

  if (!in_interrupt())
   local_irq_save(flags);
  read_lock(ep->lock);

with huge comment explaining performance number.

Or just give up and simply revert the original patch completely
and always call read_lock_irqsave().


Yeah so the reason why I had done the other epoll lock irq
optimizations was because they were painfully obvious.
ep_poll_callback(), however is a different beast, as you've
encountered. I vote for not shooting ourselves in the foot and just
dropping this patch -- most large performance benefits will come from
microbenches anyway.


Then I will send another patch which changes read_lock() on 
read_lock_irqsave(),

since simple revert of the original patch won't work.

Thanks.

--
Roman

Re: [PATCH] drm: Require PCI for selecting VGA_ARB.

[Sinan Kaya]

On 1/8/19, Paul Menzel  wrote:
> Dear Maarten,
>
>
> Thank you very much for the quick response.
>
> On 01/08/19 16:37, Maarten Lankhorst wrote:
>> Op 08-01-2019 om 16:07 schreef Paul Menzel:
>
>>> Building Linux 5.0-rc1 fails with the errors below. Please find the
>>> configuration file attached.
>>>
>>> ```
>>> $ make -j120
>>> […]
>>> drivers/gpu/vga/vgaarb.c: In function ‘__vga_tryget’:
>>> drivers/gpu/vga/vgaarb.c:286:14: error: ‘PCI_VGA_STATE_CHANGE_DECODES’
>>> undeclared (first use in this function); did you mean
>>> ‘PCI_SUBTRACTIVE_DECODE’?
>>>  flags |= PCI_VGA_STATE_CHANGE_DECODES;
>>>   ^~~~
>>>   PCI_SUBTRACTIVE_DECODE
>>> drivers/gpu/vga/vgaarb.c:286:14: note: each undeclared identifier is
>>> reported only once for each function it appears in
>>>   CC [M]  net/netfilter/xt_realm.o
>>>   CC  drivers/hid/hid-cherry.o
>>> drivers/gpu/vga/vga_switcheroo.c: In function
>>> ‘vga_switcheroo_runtime_suspend’:
>>> drivers/gpu/vga/vga_switcheroo.c:1053:2: error: implicit declaration of
>>> function ‘pci_bus_set_current_state’; did you mean ‘__set_current_state’?
>>> [-Werror=implicit-function-declaration]
>>>   pci_bus_set_current_state(pdev->bus, PCI_D3cold);
>>>   ^
>>>   __set_current_state
>>> drivers/gpu/vga/vgaarb.c:291:13: error: ‘PCI_VGA_STATE_CHANGE_BRIDGE’
>>> undeclared (first use in this function); did you mean
>>> ‘PCI_VGA_STATE_CHANGE_DECODES’?
>>> flags |= PCI_VGA_STATE_CHANGE_BRIDGE;
>>>  ^~~
>>>  PCI_VGA_STATE_CHANGE_DECODES
>>>   CC  fs/reiserfs/dir.o
>>>   LD [M]  net/tipc/tipc.o
>>> drivers/gpu/vga/vga_switcheroo.c: In function
>>> ‘vga_switcheroo_runtime_resume’:
>>> drivers/gpu/vga/vga_switcheroo.c:1067:2: error: implicit declaration of
>>> function ‘pci_wakeup_bus’; did you mean ‘__wake_up_bit’?
>>> [-Werror=implicit-function-declaration]
>>>   pci_wakeup_bus(pdev->bus);
>>>   ^~
>>>   __wake_up_bit
>>> drivers/gpu/vga/vgaarb.c:293:3: error: implicit declaration of function
>>> ‘pci_set_vga_state’; did you mean ‘pci_set_power_state’?
>>> [-Werror=implicit-function-declaration]
>>>pci_set_vga_state(conflict->pdev, false, pci_bits, flags);
>>>^
>>>pci_set_power_state
>>>   CC  fs/read_write.o
>>>   CC  drivers/hid/hid-chicony.o
>>>   CC  drivers/hid/hid-cypress.o
>>> drivers/gpu/vga/vgaarb.c: In function ‘vga_arb_device_init’:
>>> drivers/gpu/vga/vgaarb.c:1495:25: error: ‘pci_bus_type’ undeclared (first
>>> use in this function); did you mean ‘pci_pcie_type’?
>>>   bus_register_notifier(_bus_type, _notifier);
>>>  ^~~~
>>>  pci_pcie_type
>>> cc1: some warnings being treated as errors
>>> make[3]: *** [scripts/Makefile.build:277: drivers/gpu/vga/vgaarb.o] Error
>>> 1
>>> make[3]: *** Waiting for unfinished jobs
>>> […]
>>> ```
>
>> WARNING: unmet direct dependencies detected for VGA_ARB
>>   Depends on [n]: HAS_IOMEM [=y] && PCI [=n] && !S390
>>   Selected by [y]:
>>   - VGA_SWITCHEROO [=y] && HAS_IOMEM [=y] && X86 [=y] && ACPI [=y]
>>
>> So I guess you need to enable PCI, probably not a common config you're
>> using. :)
>>
>> Especially since you selected EXPERT.
>
> We have the attached defconfig, which is then integrated using
> `make olddefconfig`.
>
>> Oh well, apply this with git am --scissors?
>> -8<
>> When configuring the kernel without PCI we can still enable VGA
>> switcheroo,
>> which is not possible because VGA_ARB cannot be selected.
>>
>> Remove this by depending on PCI for !S390.
>>
>> Reported-by: Paul Menzel 
>> Signed-off-by: Maarten Lankhorst 
>> ---
>> diff --git a/drivers/gpu/vga/Kconfig b/drivers/gpu/vga/Kconfig
>> index b677e5d524e6..ef5671475870 100644
>> --- a/drivers/gpu/vga/Kconfig
>> +++ b/drivers/gpu/vga/Kconfig
>> @@ -21,6 +21,7 @@ config VGA_SWITCHEROO
>>  bool "Laptop Hybrid Graphics - GPU switching support"
>>  depends on X86
>>  depends on ACPI
>> +depends on (PCI && !S390) # For VGA_ARB
>>  select VGA_ARB
>>  help
>>Many laptops released in 2008/9/10 have two GPUs with a multiplexer
>
> Is this an effect of commit eb01d42a (PCI: consolidate PCI config entry in
> drivers/pci) as the `default y` is missing now?
>

See this :

https://patchwork.kernel.org/patch/10749209/

This change is about to go in.

>
> Kind regards,
>
> Paul
>

[PATCH] net: ethernet: mediatek: fix warning in phy_start_aneg

[Frank Wunderlich]

From: Sean Wang 

linux 5.0-rc1 shows following warning on bpi-r2/mt7623 bootup:

[ 5.170597] WARNING: CPU: 3 PID: 1 at drivers/net/phy/phy.c:548 
phy_start_aneg+0x110/0x144
[ 5.178826] called from state READY

[ 5.264111] [] (phy_start_aneg) from [] 
(mtk_init+0x414/0x47c)
[ 5.271630] r7:df5f5eec r6:c0f08c48 r5: r4:dea67800
[ 5.277256] [] (mtk_init) from [] 
(register_netdevice+0x98/0x51c)
[ 5.285035] r8: r7: r6:c0f97080 r5:c0f08c48 r4:dea67800
[ 5.291693] [] (register_netdevice) from [] 
(register_netdev+0x2c/0x44)
[ 5.299989] r8: r7:dea2e608 r6:deacea00 r5:dea2e604 r4:dea67800
[ 5.306646] [] (register_netdev) from [] 
(mtk_probe+0x668/0x7ac)
[ 5.314336] r5:dea2e604 r4:dea2e040
[ 5.317890] [] (mtk_probe) from [] 
(platform_drv_probe+0x58/0xa8)
[ 5.325670] r10:c0f86bac r9: r8:c0fbe578 r7: r6:c0f86bac 
r5:
[ 5.333445] r4:deacea10
[ 5.335963] [] (platform_drv_probe) from [] 
(really_probe+0x2d8/0x424)

maybe other boards using this generic driver are affected

Signed-off-by: Frank Wunderlich 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 399f565dd85a..e48c06874a85 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -356,6 +356,7 @@ static int mtk_phy_connect(struct net_device *dev)
linkmode_copy(dev->phydev->advertising, dev->phydev->supported);
linkmode_set_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
 dev->phydev->advertising);
+   phy_start(dev->phydev);
phy_start_aneg(dev->phydev);
 
of_node_put(np);
@@ -1821,7 +1822,6 @@ static int mtk_open(struct net_device *dev)
else
refcount_inc(>dma_refcnt);
 
-   phy_start(dev->phydev);
netif_start_queue(dev);
 
return 0;
-- 
2.17.1

Re: [PATCH v4] USB: Don't enable LPM if it's already enabled

[Kai Heng Feng]

> On Jan 8, 2019, at 11:41 PM, Greg KH  wrote:
> 
> On Mon, Dec 03, 2018 at 06:26:43PM +0800, Kai-Heng Feng wrote:
>> USB Bluetooth controller QCA ROME (0cf3:e007) sometimes stops working
>> after S3:
>> [ 165.110742] Bluetooth: hci0: using NVM file: qca/nvm_usb_0302.bin
>> [ 168.432065] Bluetooth: hci0: Failed to send body at 4 of 1953 (-110)
>> 
>> After some experiments, I found that disabling LPM can workaround the
>> issue.
>> 
>> On some platforms, the USB power is cut during S3, so the driver uses
>> reset-resume to resume the device. During port resume, LPM gets enabled
>> twice, by usb_reset_and_verify_device() and usb_port_resume().
>> 
>> So let's enable LPM for just once, as this solves the issue for the
>> device in question.
>> 
>> Also consolidate USB2 LPM functions to usb_enable_usb2_hardware_lpm()
>> and usb_disable_usb2_hardware_lpm().
> 
> I thought I asked for this to be two different patches.  One that does
> the "consolidation", and then one that fixes the bug.  You are mixing
> two different things here together, making it harder to review.
> 
> Can you please break this up and send a patch series, with the correct
> "Fixes:" tag added to the second patch that actually fixes the issue?

The consolidation itself is the fix, so I am not sure how to break this up.

In reset-resume case, LPM gets enabled twice, by
usb_reset_and_verify_device() and usb_port_resume().

If it’s a normal resume, LPM only gets enabled once, by
usb_port_resume().

Since all three checks (capable, allowed and enabled) are merged to
a single place, enabling LPM twice can be avoided, hence fixing the
issue.

Kai-Heng

> 
> thanks,
> 
> greg k-h

[PATCH] dm-switch: use struct_size() in kzalloc()

[Gustavo A. R. Silva]

One of the more common cases of allocation size calculations is finding the
size of a structure that has a zero-sized array at the end, along with memory
for some number of elements for that array. For example:

struct foo {
int stuff;
void *entry[];
};

instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);

Instead of leaving these open-coded and prone to type mistakes, we can now
use the new struct_size() helper:

instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);

This code was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/md/dm-switch.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/md/dm-switch.c b/drivers/md/dm-switch.c
index fae35caf3672..8a0f057b8122 100644
--- a/drivers/md/dm-switch.c
+++ b/drivers/md/dm-switch.c
@@ -61,8 +61,7 @@ static struct switch_ctx *alloc_switch_ctx(struct dm_target 
*ti, unsigned nr_pat
 {
struct switch_ctx *sctx;
 
-   sctx = kzalloc(sizeof(struct switch_ctx) + nr_paths * sizeof(struct 
switch_path),
-  GFP_KERNEL);
+   sctx = kzalloc(struct_size(sctx, path_list, nr_paths), GFP_KERNEL);
if (!sctx)
return NULL;
 
-- 
2.20.1

Re: [PATCH v4] usb: hub: add retry routine after intr URB submit error

[Alan Stern]

On Tue, 8 Jan 2019, Nicolas Saenz Julienne wrote:

> The hub sends hot-plug events to the host trough it's interrupt URB. The
> driver takes care of completing the URB and re-submitting it. Completion
> errors are handled in the hub_event() work, yet submission errors are
> ignored, rendering the device unresponsive. All further events are lost.
> 
> It is fairly hard to find this issue in the wild, since you have to time
> the USB hot-plug event with the URB submission failure. For instance it
> could be the system running out of memory or some malfunction in the USB
> controller driver. Nevertheless, it's pretty reasonable to think it'll
> happen sometime. One can trigger this issue using eBPF's function
> override feature (see BCC's inject.py script).
> 
> This patch adds a retry routine to the event of a submission error. The
> HUB driver will try to re-submit the URB once every second until it's
> successful or the HUB is disconnected.
> 
> As some USB subsystems already take care of this issue, the
> implementation was inspired from usbhid/hid_core.c's.
> 
> Signed-off-by: Nicolas Saenz Julienne 
> Reviewed-by: Oliver Neukum 
> 
> ---
> 
> v4:
>   - Add Oliver's Reviewed-by
>   - Make timeout calculation simpler
> 
> v3: As per Oliver's request:
>   - Take care of race condition between disconnect and irq
> 
> v2: as per Alan's and Oliver's comments:
>   - Rename timer
>   - Delete the timer on disconnect
>   - Don't reset HUB nor exponential slowdown the timer, 1s fixed retry
> period
>   - Check for -ESHUTDOWN prior kicking the timer
> 
>  drivers/usb/core/hub.c | 43 --
>  drivers/usb/core/hub.h |  2 ++
>  2 files changed, 39 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 1d1e61e980f3..713ab85332f8 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -607,6 +607,36 @@ static int hub_port_status(struct usb_hub *hub, int 
> port1,
>  status, change, NULL);
>  }
>  
> +static void hub_resubmit_irq_urb(struct usb_hub *hub)
> +{
> + unsigned long flags;
> + int status;
> +
> + spin_lock_irqsave(>irq_urb_lock, flags);
> +
> + if (hub->quiescing) {
> + spin_unlock_irqrestore(>irq_urb_lock, flags);
> + return;
> + }
> +
> + status = usb_submit_urb(hub->urb, GFP_ATOMIC);
> + if (status && status != -ENODEV && status != -EPERM &&
> + status != -ESHUTDOWN) {
> + dev_err(hub->intfdev, "resubmit --> %d\n", status);
> + mod_timer(>irq_urb_retry, jiffies + HZ);
> + }
> +
> + spin_unlock_irqrestore(>irq_urb_lock, flags);
> +}
> +
> +static void hub_retry_irq_urb(struct timer_list *t)
> +{
> + struct usb_hub *hub = from_timer(hub, t, irq_urb_retry);
> +
> + hub_resubmit_irq_urb(hub);
> +}
> +
> +
>  static void kick_hub_wq(struct usb_hub *hub)
>  {
>   struct usb_interface *intf;
> @@ -709,12 +739,7 @@ static void hub_irq(struct urb *urb)
>   kick_hub_wq(hub);
>  
>  resubmit:
> - if (hub->quiescing)
> - return;
> -
> - status = usb_submit_urb(hub->urb, GFP_ATOMIC);
> - if (status != 0 && status != -ENODEV && status != -EPERM)
> - dev_err(hub->intfdev, "resubmit --> %d\n", status);
> + hub_resubmit_irq_urb(hub);
>  }
>  
>  /* USB 2.0 spec Section 11.24.2.3 */
> @@ -1264,10 +1289,13 @@ enum hub_quiescing_type {
>  static void hub_quiesce(struct usb_hub *hub, enum hub_quiescing_type type)
>  {
>   struct usb_device *hdev = hub->hdev;
> + unsigned long flags;
>   int i;
>  
>   /* hub_wq and related activity won't re-trigger */
> + spin_lock_irqsave(>irq_urb_lock, flags);
>   hub->quiescing = 1;
> + spin_unlock_irqrestore(>irq_urb_lock, flags);
>  
>   if (type != HUB_SUSPEND) {
>   /* Disconnect all the children */
> @@ -1278,6 +1306,7 @@ static void hub_quiesce(struct usb_hub *hub, enum 
> hub_quiescing_type type)
>   }
>  
>   /* Stop hub_wq and related activity */
> + del_timer_sync(>irq_urb_retry);
>   usb_kill_urb(hub->urb);
>   if (hub->has_indicators)
>   cancel_delayed_work_sync(>leds);
> @@ -1810,6 +1839,8 @@ static int hub_probe(struct usb_interface *intf, const 
> struct usb_device_id *id)
>   INIT_DELAYED_WORK(>leds, led_work);
>   INIT_DELAYED_WORK(>init_work, NULL);
>   INIT_WORK(>events, hub_event);
> + spin_lock_init(>irq_urb_lock);
> + timer_setup(>irq_urb_retry, hub_retry_irq_urb, 0);
>   usb_get_intf(intf);
>   usb_get_dev(hdev);
>  
> diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
> index 4accfb63f7dc..a9e24e4b8df1 100644
> --- a/drivers/usb/core/hub.h
> +++ b/drivers/usb/core/hub.h
> @@ -69,6 +69,8 @@ struct usb_hub {
>   struct delayed_work leds;
>   struct delayed_work init_work;
>   struct work_struct  events;
> + spinlock_t  irq_urb_lock;

[PATCH] mtd: gen_probe: Use struct_size() in kmalloc()

[Gustavo A. R. Silva]

One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:

struct foo {
int stuff;
void *entry[];
};

instance = kmalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);

Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:

instance = kmalloc(struct_size(instance, entry, count), GFP_KERNEL);

This code was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/mtd/chips/gen_probe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/chips/gen_probe.c b/drivers/mtd/chips/gen_probe.c
index 837b04ab96a9..839ed40625d6 100644
--- a/drivers/mtd/chips/gen_probe.c
+++ b/drivers/mtd/chips/gen_probe.c
@@ -135,7 +135,7 @@ static struct cfi_private *genprobe_ident_chips(struct 
map_info *map, struct chi
 * our caller, and copy the appropriate data into them.
 */
 
-   retcfi = kmalloc(sizeof(struct cfi_private) + cfi.numchips * 
sizeof(struct flchip), GFP_KERNEL);
+   retcfi = kmalloc(struct_size(retcfi, chips, cfi.numchips), GFP_KERNEL);
 
if (!retcfi) {
kfree(cfi.cfiq);
-- 
2.20.1

[PATCH] dmaengine: timb_dma: Use struct_size() in kzalloc()

[Gustavo A. R. Silva]

One of the more common cases of allocation size calculations is finding the
size of a structure that has a zero-sized array at the end, along with memory
for some number of elements for that array. For example:

struct foo {
int stuff;
void *entry[];
};

instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);

Instead of leaving these open-coded and prone to type mistakes, we can now
use the new struct_size() helper:

instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);

This code was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/dma/timb_dma.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/timb_dma.c b/drivers/dma/timb_dma.c
index fc0f9c8766a8..afbb1c95b721 100644
--- a/drivers/dma/timb_dma.c
+++ b/drivers/dma/timb_dma.c
@@ -643,8 +643,8 @@ static int td_probe(struct platform_device *pdev)
DRIVER_NAME))
return -EBUSY;
 
-   td  = kzalloc(sizeof(struct timb_dma) +
-   sizeof(struct timb_dma_chan) * pdata->nr_channels, GFP_KERNEL);
+   td  = kzalloc(struct_size(td, channels, pdata->nr_channels),
+ GFP_KERNEL);
if (!td) {
err = -ENOMEM;
goto err_release_region;
-- 
2.20.1

Re: [PATCH] drm: Require PCI for selecting VGA_ARB.

[Paul Menzel]

Dear Maarten,


Thank you very much for the quick response.

On 01/08/19 16:37, Maarten Lankhorst wrote:
> Op 08-01-2019 om 16:07 schreef Paul Menzel:

>> Building Linux 5.0-rc1 fails with the errors below. Please find the
>> configuration file attached.
>>
>> ```
>> $ make -j120
>> […]
>> drivers/gpu/vga/vgaarb.c: In function ‘__vga_tryget’:
>> drivers/gpu/vga/vgaarb.c:286:14: error: ‘PCI_VGA_STATE_CHANGE_DECODES’ 
>> undeclared (first use in this function); did you mean 
>> ‘PCI_SUBTRACTIVE_DECODE’?
>>  flags |= PCI_VGA_STATE_CHANGE_DECODES;
>>   ^~~~
>>   PCI_SUBTRACTIVE_DECODE
>> drivers/gpu/vga/vgaarb.c:286:14: note: each undeclared identifier is 
>> reported only once for each function it appears in
>>   CC [M]  net/netfilter/xt_realm.o
>>   CC  drivers/hid/hid-cherry.o
>> drivers/gpu/vga/vga_switcheroo.c: In function 
>> ‘vga_switcheroo_runtime_suspend’:
>> drivers/gpu/vga/vga_switcheroo.c:1053:2: error: implicit declaration of 
>> function ‘pci_bus_set_current_state’; did you mean ‘__set_current_state’? 
>> [-Werror=implicit-function-declaration]
>>   pci_bus_set_current_state(pdev->bus, PCI_D3cold);
>>   ^
>>   __set_current_state
>> drivers/gpu/vga/vgaarb.c:291:13: error: ‘PCI_VGA_STATE_CHANGE_BRIDGE’ 
>> undeclared (first use in this function); did you mean 
>> ‘PCI_VGA_STATE_CHANGE_DECODES’?
>> flags |= PCI_VGA_STATE_CHANGE_BRIDGE;
>>  ^~~
>>  PCI_VGA_STATE_CHANGE_DECODES
>>   CC  fs/reiserfs/dir.o
>>   LD [M]  net/tipc/tipc.o
>> drivers/gpu/vga/vga_switcheroo.c: In function 
>> ‘vga_switcheroo_runtime_resume’:
>> drivers/gpu/vga/vga_switcheroo.c:1067:2: error: implicit declaration of 
>> function ‘pci_wakeup_bus’; did you mean ‘__wake_up_bit’? 
>> [-Werror=implicit-function-declaration]
>>   pci_wakeup_bus(pdev->bus);
>>   ^~
>>   __wake_up_bit
>> drivers/gpu/vga/vgaarb.c:293:3: error: implicit declaration of function 
>> ‘pci_set_vga_state’; did you mean ‘pci_set_power_state’? 
>> [-Werror=implicit-function-declaration]
>>pci_set_vga_state(conflict->pdev, false, pci_bits, flags);
>>^
>>pci_set_power_state
>>   CC  fs/read_write.o
>>   CC  drivers/hid/hid-chicony.o
>>   CC  drivers/hid/hid-cypress.o
>> drivers/gpu/vga/vgaarb.c: In function ‘vga_arb_device_init’:
>> drivers/gpu/vga/vgaarb.c:1495:25: error: ‘pci_bus_type’ undeclared (first 
>> use in this function); did you mean ‘pci_pcie_type’?
>>   bus_register_notifier(_bus_type, _notifier);
>>  ^~~~
>>  pci_pcie_type
>> cc1: some warnings being treated as errors
>> make[3]: *** [scripts/Makefile.build:277: drivers/gpu/vga/vgaarb.o] Error 1
>> make[3]: *** Waiting for unfinished jobs
>> […]
>> ```

> WARNING: unmet direct dependencies detected for VGA_ARB
>   Depends on [n]: HAS_IOMEM [=y] && PCI [=n] && !S390
>   Selected by [y]:
>   - VGA_SWITCHEROO [=y] && HAS_IOMEM [=y] && X86 [=y] && ACPI [=y]
> 
> So I guess you need to enable PCI, probably not a common config you're using. 
> :)
> 
> Especially since you selected EXPERT.

We have the attached defconfig, which is then integrated using
`make olddefconfig`.

> Oh well, apply this with git am --scissors?
> -8<
> When configuring the kernel without PCI we can still enable VGA switcheroo,
> which is not possible because VGA_ARB cannot be selected.
> 
> Remove this by depending on PCI for !S390.
> 
> Reported-by: Paul Menzel 
> Signed-off-by: Maarten Lankhorst 
> ---
> diff --git a/drivers/gpu/vga/Kconfig b/drivers/gpu/vga/Kconfig
> index b677e5d524e6..ef5671475870 100644
> --- a/drivers/gpu/vga/Kconfig
> +++ b/drivers/gpu/vga/Kconfig
> @@ -21,6 +21,7 @@ config VGA_SWITCHEROO
>   bool "Laptop Hybrid Graphics - GPU switching support"
>   depends on X86
>   depends on ACPI
> + depends on (PCI && !S390) # For VGA_ARB
>   select VGA_ARB
>   help
> Many laptops released in 2008/9/10 have two GPUs with a multiplexer

Is this an effect of commit eb01d42a (PCI: consolidate PCI config entry in
drivers/pci) as the `default y` is missing now?


Kind regards,

Paul
cat >.config <<-EOF
CONFIG_LOCALVERSION="$KERNELLOCAL"
CONFIG_KERNEL_BZIP2=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_AUDIT=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_CGROUPS=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_BLK_CGROUP=y
CONFIG_CGROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
CONFIG_RT_GROUP_SCHED=y
CONFIG_CGROUP_PIDS=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_HUGETLB=y
CONFIG_CPUSETS=y
CONFIG_CGROUP_DEVICE=y

Re: Regression in v5.0-rc1 with autosuspend hrtimers

[Tony Lindgren]

* Vincent Guittot  [190108 08:00]:
> Hi Tony,
> 
> On Tue, 8 Jan 2019 at 00:38, Tony Lindgren  wrote:
> >
> > Hi all,
> >
> > Looks like commit 8234f6734c5d ("PM-runtime: Switch autosuspend
> > over to using hrtimers") caused a regression on at least
> > omap5-uevm where 8250 UART rx wake no longer works. I have not
> > noticed this happening on others so far.
> >
> > The devices I've tested all are using 8250 with dedicated
> > wakeirqs configured for the rx pin. I can see the interrupt
> > increase on omap5-uevm after some one or more keypresses,
> > but then nothing. It seems that the uart just falls back
> > asleep right away or something.
> >
> > Any ideas what might be going wrong?
> 
> What is the autosuspend value ? Can it be that the autosuspend is set
> to a short value but was finally greater than 10-20ms on arm32. And
> now the autosuspend happens before and this has changed the sequence ?

It's set to 3 seconds. The difference between let's say
C-A9 pandaboard (that is working) compared to C-A15 omap5-uevm
is that the C-A15 has arch_timer in use. Other than that things
should behave more or less the same way.

Hmm so could it be that we now rely on timers that that may
not be capable of waking up the system from idle states with
hrtimer?

Regards,

Tony

[PATCH] mtd: cfi: cmdset_0001: Use struct_size() in kmalloc()

[Gustavo A. R. Silva]

One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:

struct foo {
int stuff;
void *entry[];
};

instance = kmalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);

Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:

instance = kmalloc(struct_size(instance, entry, count), GFP_KERNEL);

This code was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/mtd/chips/cfi_cmdset_0001.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c 
b/drivers/mtd/chips/cfi_cmdset_0001.c
index 6e8e7b1bb34b..79a53cb8507b 100644
--- a/drivers/mtd/chips/cfi_cmdset_0001.c
+++ b/drivers/mtd/chips/cfi_cmdset_0001.c
@@ -756,7 +756,8 @@ static int cfi_intelext_partition_fixup(struct mtd_info 
*mtd,
}
 
numvirtchips = cfi->numchips * numparts;
-   newcfi = kmalloc(sizeof(struct cfi_private) + numvirtchips * 
sizeof(struct flchip), GFP_KERNEL);
+   newcfi = kmalloc(struct_size(newcfi, chips, numvirtchips),
+GFP_KERNEL);
if (!newcfi)
return -ENOMEM;
shared = kmalloc_array(cfi->numchips,
-- 
2.20.1