Re: [RFC] regmap-irq: add "main register" and level-irq support

[Matti Vaittinen]

Hello Again Mark,

On Wed, Dec 05, 2018 at 05:27:01PM +, Mark Brown wrote:
> On Wed, Dec 05, 2018 at 10:22:51AM +0200, Matti Vaittinen wrote:
> > On Tue, Dec 04, 2018 at 05:21:37PM +, Mark Brown wrote:
> > > On Fri, Nov 30, 2018 at 10:59:08AM +0200, Matti Vaittinen wrote:
> 
> > > This sounds exactly like the wm831x which uses cascaded irqchips for
> > > this, though not regmap-irq.
> 
> > Yep. I guess I could do cascaded chips - but I would like to use the
> > regmap-irq for this driver. Maybe we could change regmap-irq so that it
> > would be possible to not give the DT node from regmap for this chip?
> > This was actually my first thought - but then I felt that having two irq
> > chips for one device is a bit hacky - and hence I decided to see how
> > regmap-irq could be changed to support the 'main irq status' register
> > usage. I think this 'main register' setup is pretty common design.
> 
> I'm not sure I see it as particularly hacky - it's using features that
> the frameworks provide to do the fan out, that just seems like making
> use of existing framework features.
> 
> > > I suspect the idiomatic way to handle this in DT is to make DT nodes
> > > (and devices) for the subfunction interrupt controllers and expose the
> > > internal structure of the chip to the DT.
> 
> > Yes. This would be one approach - but I am not sure how DT guys see
> > this. I may be wrong but I have a feeling Rob prefers having only one DT
> > node describing single device. But for me it would make sense to have
> > own node for GPIO - especially because the GPIO is only IRQ controller
> 
> Well, it kind of depends if you see the sub-interrupt controllers as
> independent devices or not (at the hardware level they will be).
> 
> > which really is visible outside the chip. But here we still hit the same
> > problem if we want to use regmap-irq. Regmap-irq still knows only the
> > i2c device DT node. Currently there is no way to tell regmap-irq to use
> > the sub-node.
> 
> If they're full subdevices you'd be pointing at the relevant platform
> device anyway.

I am not sure if I have explained me well enough =) When we look at
regmap_add_irq_chip we see that it creates the IRQ domains. And we
further see:

d->domain = irq_domain_add_linear(map->dev->of_node,
  chip->num_irqs,
  _domain_ops, d);

where map->dev->of_node points the node added to regmap. And as we
really want to use the i2c to access registers, we should have done the
regmap using:

devm_regmap_init_i2c(i2c, );


where the i2c is the struct i2c_client *. The dev in i2c_client is the
i2c device - which has of_node pointing at the "main i2c node" - not the
sub block nodes. Hence all irq chips created by regmap_add_irq_chip for
this physical i2c slave device will point to the same DT node. 

> > >  This does make some sense as
> > > the individual interrupt controllers within the chip are clearly
> > > reusable IP blocks though it means that the chip starts looking a bit
> > > weird externally so perhaps that's not ideal and your suggestion makes
> > > sense.
> 
> > So I take this as a suggestion to continue tinkering with the 'main irq
> > register support'. Or how do you see my suggestion of making iot
> > possible to instruct the regmap-irq to not use DT for 'main irq
> > controller'? Then we could probably do cascaded controllers where only
> > the controller handling the externally visible 'sub-irqs' would be
> > bound to DT? The pitfall here is case where more than one sub-irq
> > controllers needs to be exposed to other devices. In that sense the
> > 'main irq thing' would have better 'case coverage' =) (Wow, what a fancy
> > words, maybe I am turning into a manager here :p )
> 
> I'm on the fence about the main controller idea

So am I. But I still would like to use regmap-irq no matter if I create
one or many irq chips. So please allow me to present the other idea:

Would it work if we add someting like

struct regmap_irq_chip {
const char *name;

unsigned int status_base;
unsigned int mask_base;
unsigned int unmask_base;
unsigned int ack_base;
unsigned int wake_base;
unsigned int type_base;
unsigned int irq_reg_stride;
bool mask_writeonly:1;
+   bool no_of:1;

and in the regmap_add_irq_chip do:

node = (chip->no_of) ? NULL : map->dev->of_node;
d->domain = irq_domain_add_linear(node, chip->num_irqs,
  _domain_ops, d);

Then we could have chip->no_of set for the 'main irq chip' and for those
chips we don't wan't to expose via DT. In my case I would leave no_of
unset only for the irq-chip which I created for the GPIO? Is this a
silly idea?

> > > > + * @main_status: Base main status register address. For chips which 
> > > > have
> > > > + *  interrupts arranged in separate 

Re: [RFC] regmap-irq: add "main register" and level-irq support

[Matti Vaittinen]

Hello Again Mark,

On Wed, Dec 05, 2018 at 05:27:01PM +, Mark Brown wrote:
> On Wed, Dec 05, 2018 at 10:22:51AM +0200, Matti Vaittinen wrote:
> > On Tue, Dec 04, 2018 at 05:21:37PM +, Mark Brown wrote:
> > > On Fri, Nov 30, 2018 at 10:59:08AM +0200, Matti Vaittinen wrote:
> 
> > > This sounds exactly like the wm831x which uses cascaded irqchips for
> > > this, though not regmap-irq.
> 
> > Yep. I guess I could do cascaded chips - but I would like to use the
> > regmap-irq for this driver. Maybe we could change regmap-irq so that it
> > would be possible to not give the DT node from regmap for this chip?
> > This was actually my first thought - but then I felt that having two irq
> > chips for one device is a bit hacky - and hence I decided to see how
> > regmap-irq could be changed to support the 'main irq status' register
> > usage. I think this 'main register' setup is pretty common design.
> 
> I'm not sure I see it as particularly hacky - it's using features that
> the frameworks provide to do the fan out, that just seems like making
> use of existing framework features.
> 
> > > I suspect the idiomatic way to handle this in DT is to make DT nodes
> > > (and devices) for the subfunction interrupt controllers and expose the
> > > internal structure of the chip to the DT.
> 
> > Yes. This would be one approach - but I am not sure how DT guys see
> > this. I may be wrong but I have a feeling Rob prefers having only one DT
> > node describing single device. But for me it would make sense to have
> > own node for GPIO - especially because the GPIO is only IRQ controller
> 
> Well, it kind of depends if you see the sub-interrupt controllers as
> independent devices or not (at the hardware level they will be).
> 
> > which really is visible outside the chip. But here we still hit the same
> > problem if we want to use regmap-irq. Regmap-irq still knows only the
> > i2c device DT node. Currently there is no way to tell regmap-irq to use
> > the sub-node.
> 
> If they're full subdevices you'd be pointing at the relevant platform
> device anyway.

I am not sure if I have explained me well enough =) When we look at
regmap_add_irq_chip we see that it creates the IRQ domains. And we
further see:

d->domain = irq_domain_add_linear(map->dev->of_node,
  chip->num_irqs,
  _domain_ops, d);

where map->dev->of_node points the node added to regmap. And as we
really want to use the i2c to access registers, we should have done the
regmap using:

devm_regmap_init_i2c(i2c, );


where the i2c is the struct i2c_client *. The dev in i2c_client is the
i2c device - which has of_node pointing at the "main i2c node" - not the
sub block nodes. Hence all irq chips created by regmap_add_irq_chip for
this physical i2c slave device will point to the same DT node. 

> > >  This does make some sense as
> > > the individual interrupt controllers within the chip are clearly
> > > reusable IP blocks though it means that the chip starts looking a bit
> > > weird externally so perhaps that's not ideal and your suggestion makes
> > > sense.
> 
> > So I take this as a suggestion to continue tinkering with the 'main irq
> > register support'. Or how do you see my suggestion of making iot
> > possible to instruct the regmap-irq to not use DT for 'main irq
> > controller'? Then we could probably do cascaded controllers where only
> > the controller handling the externally visible 'sub-irqs' would be
> > bound to DT? The pitfall here is case where more than one sub-irq
> > controllers needs to be exposed to other devices. In that sense the
> > 'main irq thing' would have better 'case coverage' =) (Wow, what a fancy
> > words, maybe I am turning into a manager here :p )
> 
> I'm on the fence about the main controller idea

So am I. But I still would like to use regmap-irq no matter if I create
one or many irq chips. So please allow me to present the other idea:

Would it work if we add someting like

struct regmap_irq_chip {
const char *name;

unsigned int status_base;
unsigned int mask_base;
unsigned int unmask_base;
unsigned int ack_base;
unsigned int wake_base;
unsigned int type_base;
unsigned int irq_reg_stride;
bool mask_writeonly:1;
+   bool no_of:1;

and in the regmap_add_irq_chip do:

node = (chip->no_of) ? NULL : map->dev->of_node;
d->domain = irq_domain_add_linear(node, chip->num_irqs,
  _domain_ops, d);

Then we could have chip->no_of set for the 'main irq chip' and for those
chips we don't wan't to expose via DT. In my case I would leave no_of
unset only for the irq-chip which I created for the GPIO? Is this a
silly idea?

> > > > + * @main_status: Base main status register address. For chips which 
> > > > have
> > > > + *  interrupts arranged in separate 

Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

[Michal Hocko]

On Fri 07-12-18 10:56:51, Pingfan Liu wrote:
[...]
> In a short word, the fix method should consider about the two factors:
> semantic of online-node and the effect on all archs

I am pretty sure there is a lot of room for unification in this area.
Nevertheless I strongly believe the bug should be fixed firs with the
simplest way and all the cleanup should be done on top.

Do I get it right that the diff worked for you and I can prepare a full
patch?

-- 
Michal Hocko
SUSE Labs

Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline

[Michal Hocko]

On Fri 07-12-18 10:56:51, Pingfan Liu wrote:
[...]
> In a short word, the fix method should consider about the two factors:
> semantic of online-node and the effect on all archs

I am pretty sure there is a lot of room for unification in this area.
Nevertheless I strongly believe the bug should be fixed firs with the
simplest way and all the cleanup should be done on top.

Do I get it right that the diff worked for you and I can prepare a full
patch?

-- 
Michal Hocko
SUSE Labs

Morning

[Joy Smith Johnson]

Hello; kindly see the attached my proposal Charities donation.


Mrs. Joy Smith Johnson.rtf
Description: RTF file

Morning

[Joy Smith Johnson]

Hello; kindly see the attached my proposal Charities donation.


Mrs. Joy Smith Johnson.rtf
Description: RTF file

Re: MADV_HUGEPAGE vs. NUMA semantic (was: Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression)

[Michal Hocko]

On Thu 06-12-18 20:31:46, Linus Torvalds wrote:
> [ Oops. different thread for me due to edited subject, so I saw this
> after replying to the earlier email by David ]

Sorry about that but I really wanted to make the actual discussion about
semantic clearly distinguished because the thread just grown too large
with back and forth that didn't lead to anywhere.

> On Thu, Dec 6, 2018 at 1:14 AM Michal Hocko  wrote:
> >
> > MADV_HUGEPAGE changes the picture because the caller expressed a need
> > for THP and is willing to go extra mile to get it.
> 
> Actually, I think MADV_HUGEPAGE should just be
> "TRANSPARENT_HUGEPAGE_ALWAYS but only for this vma".

Yes, that is the case and I didn't want to make the description more
complicated than necessary so I've focused only on the current default.
But historically we have treated defrag=always and MADV_HUGEPAGE the
same.

[...]
> >I believe that something like the below would be sensible
> > 1) THP on a local node with compaction not giving up too early
> > 2) THP on a remote node in NOWAIT mode - so no direct
> >compaction/reclaim (trigger kswapd/kcompactd only for
> >defrag=defer+madvise)
> > 3) fallback to the base page allocation
> 
> That doesn't sound insane to me. That said, the numbers David quoted
> do fairly strongly imply that local small-pages are actually preferred
> to any remote THP pages.

As I and others pointed out elsewhere remote penalty is just a part of
the picture and on its own might be quite misleading. There are other
aspects (TLB pressure, page tables overhead etc) that might amortize the
access latency.

> But *that* in turn makes for other possible questions:
> 
>  - if the reason we couldn't get a local hugepage is that we're simply
> out of local memory (huge *or* small), then maybe a remote hugepage is
> better.
> 
>Note that this now implies that the choice can be an issue of "did
> the hugepage allocation fail due to fragmentation, or due to the node
> being low of memory"

How exactly do you tell? Many systems are simply low on memory due to
caching. A clean pagecache is quite cheap to reclaim but it can be more
expensive to fault in. Do we consider it to be a viable target?

> 
> and there is the other question that I asked in the other thread
> (before subject edit):
> 
>  - how local is the load to begin with?
> 
>Relatively shortlived processes - or processes that are explicitly
> bound to a node - might have different preferences than some
> long-lived process where the CPU bounces around, and might have
> different trade-offs for the local vs remote question too.

Agreed

> So just based on David's numbers, and some wild handwaving on my part,
> a slightly more complex, but still very sensible default might be
> something like
> 
>  1) try to do a cheap local node hugepage allocation
> 
> Rationale: everybody agrees this is the best case.
> 
> But if that fails:
> 
>  2) look at compacting and the local node, but not very hard.
> 
> If there's lots of memory on the local node, but synchronous
> compaction doesn't do anything easily, just fall back to small pages.

Do we reclaim at this stage or this is mostly GFP_NOWAIT attempt?

> Rationale: local memory is generally more important than THP.
> 
> If that fails (ie local node is simply low on memory):
> 
>  3) Try to do remote THP allocation
> 
>  Rationale: Ok, we simply didn't have a lot of local memory, so
> it's not just a question of fragmentation. If it *had* been
> fragmentation, lots of small local pages would have been better than a
> remote THP page.
> 
>  Oops, remote THP allocation failed (possibly after synchronous
> remote compaction, but maybe this is where we do kcompactd).
> 
>  4) Just do any small page, and do reclaim etc. THP isn't happening,
> and it's not a priority when you're starting to feel memory pressure.

If 2) doesn't reclaim heavily (e.g. only try to reclaim clean page
cache) or even do NOWAIT (which would be even better) then I _think_
this sounds sane.

> In general, I really would want to avoid magic kernel command lines
> (or sysfs settings, or whatever) making a huge difference in behavior.
> So I really wish people would see the whole
> 'transparent_hugepage_flags' thing as a way for kernel developers to
> try different settings, not as a way for users to tune their loads.
> 
> Our default should work as sane defaults, we shouldn't have a "ok,
> let's have this sysfs tunable and let people make their own
> decisions". That's a cop-out.

Agreed. I cannot say I am happy with all the ways THP can be tuned. It
is quite confusing to say the least.

-- 
Michal Hocko
SUSE Labs

Re: MADV_HUGEPAGE vs. NUMA semantic (was: Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression)

[Michal Hocko]

On Thu 06-12-18 20:31:46, Linus Torvalds wrote:
> [ Oops. different thread for me due to edited subject, so I saw this
> after replying to the earlier email by David ]

Sorry about that but I really wanted to make the actual discussion about
semantic clearly distinguished because the thread just grown too large
with back and forth that didn't lead to anywhere.

> On Thu, Dec 6, 2018 at 1:14 AM Michal Hocko  wrote:
> >
> > MADV_HUGEPAGE changes the picture because the caller expressed a need
> > for THP and is willing to go extra mile to get it.
> 
> Actually, I think MADV_HUGEPAGE should just be
> "TRANSPARENT_HUGEPAGE_ALWAYS but only for this vma".

Yes, that is the case and I didn't want to make the description more
complicated than necessary so I've focused only on the current default.
But historically we have treated defrag=always and MADV_HUGEPAGE the
same.

[...]
> >I believe that something like the below would be sensible
> > 1) THP on a local node with compaction not giving up too early
> > 2) THP on a remote node in NOWAIT mode - so no direct
> >compaction/reclaim (trigger kswapd/kcompactd only for
> >defrag=defer+madvise)
> > 3) fallback to the base page allocation
> 
> That doesn't sound insane to me. That said, the numbers David quoted
> do fairly strongly imply that local small-pages are actually preferred
> to any remote THP pages.

As I and others pointed out elsewhere remote penalty is just a part of
the picture and on its own might be quite misleading. There are other
aspects (TLB pressure, page tables overhead etc) that might amortize the
access latency.

> But *that* in turn makes for other possible questions:
> 
>  - if the reason we couldn't get a local hugepage is that we're simply
> out of local memory (huge *or* small), then maybe a remote hugepage is
> better.
> 
>Note that this now implies that the choice can be an issue of "did
> the hugepage allocation fail due to fragmentation, or due to the node
> being low of memory"

How exactly do you tell? Many systems are simply low on memory due to
caching. A clean pagecache is quite cheap to reclaim but it can be more
expensive to fault in. Do we consider it to be a viable target?

> 
> and there is the other question that I asked in the other thread
> (before subject edit):
> 
>  - how local is the load to begin with?
> 
>Relatively shortlived processes - or processes that are explicitly
> bound to a node - might have different preferences than some
> long-lived process where the CPU bounces around, and might have
> different trade-offs for the local vs remote question too.

Agreed

> So just based on David's numbers, and some wild handwaving on my part,
> a slightly more complex, but still very sensible default might be
> something like
> 
>  1) try to do a cheap local node hugepage allocation
> 
> Rationale: everybody agrees this is the best case.
> 
> But if that fails:
> 
>  2) look at compacting and the local node, but not very hard.
> 
> If there's lots of memory on the local node, but synchronous
> compaction doesn't do anything easily, just fall back to small pages.

Do we reclaim at this stage or this is mostly GFP_NOWAIT attempt?

> Rationale: local memory is generally more important than THP.
> 
> If that fails (ie local node is simply low on memory):
> 
>  3) Try to do remote THP allocation
> 
>  Rationale: Ok, we simply didn't have a lot of local memory, so
> it's not just a question of fragmentation. If it *had* been
> fragmentation, lots of small local pages would have been better than a
> remote THP page.
> 
>  Oops, remote THP allocation failed (possibly after synchronous
> remote compaction, but maybe this is where we do kcompactd).
> 
>  4) Just do any small page, and do reclaim etc. THP isn't happening,
> and it's not a priority when you're starting to feel memory pressure.

If 2) doesn't reclaim heavily (e.g. only try to reclaim clean page
cache) or even do NOWAIT (which would be even better) then I _think_
this sounds sane.

> In general, I really would want to avoid magic kernel command lines
> (or sysfs settings, or whatever) making a huge difference in behavior.
> So I really wish people would see the whole
> 'transparent_hugepage_flags' thing as a way for kernel developers to
> try different settings, not as a way for users to tune their loads.
> 
> Our default should work as sane defaults, we shouldn't have a "ok,
> let's have this sysfs tunable and let people make their own
> decisions". That's a cop-out.

Agreed. I cannot say I am happy with all the ways THP can be tuned. It
is quite confusing to say the least.

-- 
Michal Hocko
SUSE Labs

Re: use generic DMA mapping code in powerpc V4

[Christian Zigotzky]

Good to know. Sorry because of the email.

Sent from my iPhone

> On 6. Dec 2018, at 20:36, Christoph Hellwig  wrote:
> 
>> On Thu, Dec 06, 2018 at 06:10:54PM +0100, Christian Zigotzky wrote:
>> Please don’t merge this code. We are still testing and trying to figure out 
>> where the problems are in the code.
> 
> The ones I sent pings for were either tested successfully by you
> (the zone change) or are trivial cleanups that don't affect your setup.

[PATCH v3 1/2] dmaengine: 8250_mtk_dma: add Mediatek uart DMA support

[Long Cheng]

In DMA engine framework, add 8250 mtk dma to support it.

Signed-off-by: Long Cheng 
---
 drivers/dma/mediatek/8250_mtk_dma.c |  847 +++
 drivers/dma/mediatek/Kconfig|   11 +
 drivers/dma/mediatek/Makefile   |1 +
 3 files changed, 859 insertions(+)
 create mode 100644 drivers/dma/mediatek/8250_mtk_dma.c

diff --git a/drivers/dma/mediatek/8250_mtk_dma.c 
b/drivers/dma/mediatek/8250_mtk_dma.c
new file mode 100644
index 000..a2db9ec
--- /dev/null
+++ b/drivers/dma/mediatek/8250_mtk_dma.c
@@ -0,0 +1,847 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Mediatek 8250 DMA driver.
+ *
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Long Cheng 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../virt-dma.h"
+
+#define MTK_APDMA_DEFAULT_REQUESTS 127
+#define MTK_APDMA_CHANNELS (CONFIG_SERIAL_8250_NR_UARTS * 2)
+
+#define VFF_EN_B   BIT(0)
+#define VFF_STOP_B BIT(0)
+#define VFF_FLUSH_BBIT(0)
+#define VFF_4G_SUPPORT_B   BIT(0)
+#define VFF_RX_INT_EN0_B   BIT(0)  /*rx valid size >=  vff thre*/
+#define VFF_RX_INT_EN1_B   BIT(1)
+#define VFF_TX_INT_EN_BBIT(0)  /*tx left size >= vff thre*/
+#define VFF_WARM_RST_B BIT(0)
+#define VFF_RX_INT_FLAG_CLR_B  (BIT(0) | BIT(1))
+#define VFF_TX_INT_FLAG_CLR_B  0
+#define VFF_STOP_CLR_B 0
+#define VFF_FLUSH_CLR_B0
+#define VFF_INT_EN_CLR_B   0
+#define VFF_4G_SUPPORT_CLR_B   0
+
+/* interrupt trigger level for tx */
+#define VFF_TX_THRE(n) ((n) * 7 / 8)
+/* interrupt trigger level for rx */
+#define VFF_RX_THRE(n) ((n) * 3 / 4)
+
+#define MTK_DMA_RING_SIZE  0xU
+/* invert this bit when wrap ring head again*/
+#define MTK_DMA_RING_WRAP  0x1U
+
+#define VFF_INT_FLAG   0x00
+#define VFF_INT_EN 0x04
+#define VFF_EN 0x08
+#define VFF_RST0x0c
+#define VFF_STOP   0x10
+#define VFF_FLUSH  0x14
+#define VFF_ADDR   0x1c
+#define VFF_LEN0x24
+#define VFF_THRE   0x28
+#define VFF_WPT0x2c
+#define VFF_RPT0x30
+/*TX: the buffer size HW can read. RX: the buffer size SW can read.*/
+#define VFF_VALID_SIZE 0x3c
+/*TX: the buffer size SW can write. RX: the buffer size HW can write.*/
+#define VFF_LEFT_SIZE  0x40
+#define VFF_DEBUG_STATUS   0x50
+#define VFF_4G_SUPPORT 0x54
+
+struct mtk_dmadev {
+   struct dma_device ddev;
+   void __iomem *mem_base[MTK_APDMA_CHANNELS];
+   spinlock_t lock; /* dma dev lock */
+   struct tasklet_struct task;
+   struct list_head pending;
+   struct clk *clk;
+   unsigned int dma_requests;
+   bool support_33bits;
+   unsigned int dma_irq[MTK_APDMA_CHANNELS];
+   struct mtk_chan *ch[MTK_APDMA_CHANNELS];
+};
+
+struct mtk_chan {
+   struct virt_dma_chan vc;
+   struct list_head node;
+   struct dma_slave_config cfg;
+   void __iomem *base;
+   struct mtk_dma_desc *desc;
+
+   bool stop;
+   bool requested;
+
+   unsigned int rx_status;
+};
+
+struct mtk_dma_sg {
+   dma_addr_t addr;
+   unsigned int en;/* number of elements (24-bit) */
+   unsigned int fn;/* number of frames (16-bit) */
+};
+
+struct mtk_dma_desc {
+   struct virt_dma_desc vd;
+   enum dma_transfer_direction dir;
+
+   unsigned int sglen;
+   struct mtk_dma_sg sg[0];
+
+   unsigned int len;
+};
+
+static inline struct mtk_dmadev *to_mtk_dma_dev(struct dma_device *d)
+{
+   return container_of(d, struct mtk_dmadev, ddev);
+}
+
+static inline struct mtk_chan *to_mtk_dma_chan(struct dma_chan *c)
+{
+   return container_of(c, struct mtk_chan, vc.chan);
+}
+
+static inline struct mtk_dma_desc *to_mtk_dma_desc
+   (struct dma_async_tx_descriptor *t)
+{
+   return container_of(t, struct mtk_dma_desc, vd.tx);
+}
+
+static void mtk_dma_chan_write(struct mtk_chan *c,
+  unsigned int reg, unsigned int val)
+{
+   writel(val, c->base + reg);
+}
+
+static unsigned int mtk_dma_chan_read(struct mtk_chan *c, unsigned int reg)
+{
+   return readl(c->base + reg);
+}
+
+static void mtk_dma_desc_free(struct virt_dma_desc *vd)
+{
+   struct dma_chan *chan = vd->tx.chan;
+   struct mtk_chan *c = to_mtk_dma_chan(chan);
+
+   kfree(c->desc);
+   c->desc = NULL;
+}
+
+static int mtk_dma_clk_enable(struct mtk_dmadev *mtkd)
+{
+   int ret;
+
+   ret = clk_prepare_enable(mtkd->clk);
+   if (ret) {
+   dev_err(mtkd->ddev.dev, "Couldn't enable the clock\n");
+   return ret;
+   }
+
+   return 0;
+}
+
+static void mtk_dma_clk_disable(struct 

Re: [PATCH v2 2/3] arm64: dts: allwinner: a64: Add A64 CSI controller

[Maxime Ripard]

On Thu, Dec 06, 2018 at 06:07:59PM +0100, Michael Nazzareno Trimarchi wrote:
> On Thu, Dec 6, 2018 at 4:34 PM Maxime Ripard  
> wrote:
> > On Thu, Dec 06, 2018 at 06:53:05PM +0530, Jagan Teki wrote:
> > > Allwinner A64 CSI controller has similar features as like in
> > > H3, So add support for A64 via H3 fallback.
> > >
> > > Also updated CSI_SCLK to use 300MHz via assigned-clocks, since
> > > the default clock 600MHz seems unable to drive the sensor(ov5640)
> > > to capture the image.
> > >
> > > Signed-off-by: Jagan Teki 
> > > ---
> > > Changes for v2:
> > > - Use CSI_SCLK to 300MHz
> > >
> > >  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23 +++
> > >  1 file changed, 23 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
> > > b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > > index 384c417cb7a2..d7ab0006ebce 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > > @@ -532,6 +532,12 @@
> > >   interrupt-controller;
> > >   #interrupt-cells = <3>;
> > >
> > > + csi_pins: csi-pins {
> > > + pins = "PE0", "PE2", "PE3", "PE4", "PE5", 
> > > "PE6",
> > > +"PE7", "PE8", "PE9", "PE10", "PE11";
> > > + function = "csi0";
> > > + };
> > > +
> > >   i2c0_pins: i2c0_pins {
> > >   pins = "PH0", "PH1";
> > >   function = "i2c0";
> > > @@ -899,6 +905,23 @@
> > >   status = "disabled";
> > >   };
> > >
> > > + csi: csi@1cb {
> > > + compatible = "allwinner,sun50i-a64-csi",
> > > +  "allwinner,sun8i-h3-csi";
> > > + reg = <0x01cb 0x1000>;
> > > + interrupts = ;
> > > + clocks = < CLK_BUS_CSI>,
> > > +  < CLK_CSI_SCLK>,
> > > +  < CLK_DRAM_CSI>;
> > > + clock-names = "bus", "mod", "ram";
> > > + resets = < RST_BUS_CSI>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <_pins>;
> > > + assigned-clocks = < CLK_CSI_SCLK>;
> > > + assigned-clock-rates = <3>;
> >
> > That should be enforced in the driver.
> >
> 
> We are not really sure what is the best here. Our first idea was to
> put in the board file and then Jagan
> decide to put in dtsi. We don't have enough coverage of camera on this
> CPU and I prefer to stay with this
> minimal change that does not impact the driver.

The thing is that:
  - in this commit log, you're stating that it depends on the sensor,
which indicates that this would be a board level addition
  - In another patch series, Jagan reported IIRC that it actually
depends on the resolution, so it doesn't belong in the DT at all
  - And then, you don't even have any guarantee on the clock rate. The
sole guarantee you have is that when your driver will probe, the
rate will be close to those 300MHz. That's it. It might completely
change after the driver has probed, or be rounded to something
else entirely, who knows.

So really, putting it in the DT is nothing but a hack.

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

[PATCH v3 1/2] dmaengine: 8250_mtk_dma: add Mediatek uart DMA support

[Long Cheng]

In DMA engine framework, add 8250 mtk dma to support it.

Signed-off-by: Long Cheng 
---
 drivers/dma/mediatek/8250_mtk_dma.c |  847 +++
 drivers/dma/mediatek/Kconfig|   11 +
 drivers/dma/mediatek/Makefile   |1 +
 3 files changed, 859 insertions(+)
 create mode 100644 drivers/dma/mediatek/8250_mtk_dma.c

diff --git a/drivers/dma/mediatek/8250_mtk_dma.c 
b/drivers/dma/mediatek/8250_mtk_dma.c
new file mode 100644
index 000..a2db9ec
--- /dev/null
+++ b/drivers/dma/mediatek/8250_mtk_dma.c
@@ -0,0 +1,847 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Mediatek 8250 DMA driver.
+ *
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Long Cheng 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../virt-dma.h"
+
+#define MTK_APDMA_DEFAULT_REQUESTS 127
+#define MTK_APDMA_CHANNELS (CONFIG_SERIAL_8250_NR_UARTS * 2)
+
+#define VFF_EN_B   BIT(0)
+#define VFF_STOP_B BIT(0)
+#define VFF_FLUSH_BBIT(0)
+#define VFF_4G_SUPPORT_B   BIT(0)
+#define VFF_RX_INT_EN0_B   BIT(0)  /*rx valid size >=  vff thre*/
+#define VFF_RX_INT_EN1_B   BIT(1)
+#define VFF_TX_INT_EN_BBIT(0)  /*tx left size >= vff thre*/
+#define VFF_WARM_RST_B BIT(0)
+#define VFF_RX_INT_FLAG_CLR_B  (BIT(0) | BIT(1))
+#define VFF_TX_INT_FLAG_CLR_B  0
+#define VFF_STOP_CLR_B 0
+#define VFF_FLUSH_CLR_B0
+#define VFF_INT_EN_CLR_B   0
+#define VFF_4G_SUPPORT_CLR_B   0
+
+/* interrupt trigger level for tx */
+#define VFF_TX_THRE(n) ((n) * 7 / 8)
+/* interrupt trigger level for rx */
+#define VFF_RX_THRE(n) ((n) * 3 / 4)
+
+#define MTK_DMA_RING_SIZE  0xU
+/* invert this bit when wrap ring head again*/
+#define MTK_DMA_RING_WRAP  0x1U
+
+#define VFF_INT_FLAG   0x00
+#define VFF_INT_EN 0x04
+#define VFF_EN 0x08
+#define VFF_RST0x0c
+#define VFF_STOP   0x10
+#define VFF_FLUSH  0x14
+#define VFF_ADDR   0x1c
+#define VFF_LEN0x24
+#define VFF_THRE   0x28
+#define VFF_WPT0x2c
+#define VFF_RPT0x30
+/*TX: the buffer size HW can read. RX: the buffer size SW can read.*/
+#define VFF_VALID_SIZE 0x3c
+/*TX: the buffer size SW can write. RX: the buffer size HW can write.*/
+#define VFF_LEFT_SIZE  0x40
+#define VFF_DEBUG_STATUS   0x50
+#define VFF_4G_SUPPORT 0x54
+
+struct mtk_dmadev {
+   struct dma_device ddev;
+   void __iomem *mem_base[MTK_APDMA_CHANNELS];
+   spinlock_t lock; /* dma dev lock */
+   struct tasklet_struct task;
+   struct list_head pending;
+   struct clk *clk;
+   unsigned int dma_requests;
+   bool support_33bits;
+   unsigned int dma_irq[MTK_APDMA_CHANNELS];
+   struct mtk_chan *ch[MTK_APDMA_CHANNELS];
+};
+
+struct mtk_chan {
+   struct virt_dma_chan vc;
+   struct list_head node;
+   struct dma_slave_config cfg;
+   void __iomem *base;
+   struct mtk_dma_desc *desc;
+
+   bool stop;
+   bool requested;
+
+   unsigned int rx_status;
+};
+
+struct mtk_dma_sg {
+   dma_addr_t addr;
+   unsigned int en;/* number of elements (24-bit) */
+   unsigned int fn;/* number of frames (16-bit) */
+};
+
+struct mtk_dma_desc {
+   struct virt_dma_desc vd;
+   enum dma_transfer_direction dir;
+
+   unsigned int sglen;
+   struct mtk_dma_sg sg[0];
+
+   unsigned int len;
+};
+
+static inline struct mtk_dmadev *to_mtk_dma_dev(struct dma_device *d)
+{
+   return container_of(d, struct mtk_dmadev, ddev);
+}
+
+static inline struct mtk_chan *to_mtk_dma_chan(struct dma_chan *c)
+{
+   return container_of(c, struct mtk_chan, vc.chan);
+}
+
+static inline struct mtk_dma_desc *to_mtk_dma_desc
+   (struct dma_async_tx_descriptor *t)
+{
+   return container_of(t, struct mtk_dma_desc, vd.tx);
+}
+
+static void mtk_dma_chan_write(struct mtk_chan *c,
+  unsigned int reg, unsigned int val)
+{
+   writel(val, c->base + reg);
+}
+
+static unsigned int mtk_dma_chan_read(struct mtk_chan *c, unsigned int reg)
+{
+   return readl(c->base + reg);
+}
+
+static void mtk_dma_desc_free(struct virt_dma_desc *vd)
+{
+   struct dma_chan *chan = vd->tx.chan;
+   struct mtk_chan *c = to_mtk_dma_chan(chan);
+
+   kfree(c->desc);
+   c->desc = NULL;
+}
+
+static int mtk_dma_clk_enable(struct mtk_dmadev *mtkd)
+{
+   int ret;
+
+   ret = clk_prepare_enable(mtkd->clk);
+   if (ret) {
+   dev_err(mtkd->ddev.dev, "Couldn't enable the clock\n");
+   return ret;
+   }
+
+   return 0;
+}
+
+static void mtk_dma_clk_disable(struct 

Re: [PATCH v2 2/3] arm64: dts: allwinner: a64: Add A64 CSI controller

[Maxime Ripard]

On Thu, Dec 06, 2018 at 06:07:59PM +0100, Michael Nazzareno Trimarchi wrote:
> On Thu, Dec 6, 2018 at 4:34 PM Maxime Ripard  
> wrote:
> > On Thu, Dec 06, 2018 at 06:53:05PM +0530, Jagan Teki wrote:
> > > Allwinner A64 CSI controller has similar features as like in
> > > H3, So add support for A64 via H3 fallback.
> > >
> > > Also updated CSI_SCLK to use 300MHz via assigned-clocks, since
> > > the default clock 600MHz seems unable to drive the sensor(ov5640)
> > > to capture the image.
> > >
> > > Signed-off-by: Jagan Teki 
> > > ---
> > > Changes for v2:
> > > - Use CSI_SCLK to 300MHz
> > >
> > >  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23 +++
> > >  1 file changed, 23 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
> > > b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > > index 384c417cb7a2..d7ab0006ebce 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > > @@ -532,6 +532,12 @@
> > >   interrupt-controller;
> > >   #interrupt-cells = <3>;
> > >
> > > + csi_pins: csi-pins {
> > > + pins = "PE0", "PE2", "PE3", "PE4", "PE5", 
> > > "PE6",
> > > +"PE7", "PE8", "PE9", "PE10", "PE11";
> > > + function = "csi0";
> > > + };
> > > +
> > >   i2c0_pins: i2c0_pins {
> > >   pins = "PH0", "PH1";
> > >   function = "i2c0";
> > > @@ -899,6 +905,23 @@
> > >   status = "disabled";
> > >   };
> > >
> > > + csi: csi@1cb {
> > > + compatible = "allwinner,sun50i-a64-csi",
> > > +  "allwinner,sun8i-h3-csi";
> > > + reg = <0x01cb 0x1000>;
> > > + interrupts = ;
> > > + clocks = < CLK_BUS_CSI>,
> > > +  < CLK_CSI_SCLK>,
> > > +  < CLK_DRAM_CSI>;
> > > + clock-names = "bus", "mod", "ram";
> > > + resets = < RST_BUS_CSI>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <_pins>;
> > > + assigned-clocks = < CLK_CSI_SCLK>;
> > > + assigned-clock-rates = <3>;
> >
> > That should be enforced in the driver.
> >
> 
> We are not really sure what is the best here. Our first idea was to
> put in the board file and then Jagan
> decide to put in dtsi. We don't have enough coverage of camera on this
> CPU and I prefer to stay with this
> minimal change that does not impact the driver.

The thing is that:
  - in this commit log, you're stating that it depends on the sensor,
which indicates that this would be a board level addition
  - In another patch series, Jagan reported IIRC that it actually
depends on the resolution, so it doesn't belong in the DT at all
  - And then, you don't even have any guarantee on the clock rate. The
sole guarantee you have is that when your driver will probe, the
rate will be close to those 300MHz. That's it. It might completely
change after the driver has probed, or be rounded to something
else entirely, who knows.

So really, putting it in the DT is nothing but a hack.

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

[PATCH v3 0/2] add uart DMA function

[Long Cheng]

In Mediatek SOCs, the uart can support DMA function.
Base on DMA engine formwork, we add the DMA code to support uart. And put the 
code under drivers/dma.

This series contains document bindings, Kconfig to control the function enable 
or not,
device tree including interrupt and dma device node, the code of UART DM

Changes compared to v2:
-remove unimportant parameters
-instead of cookie, use APIs of virtual channel.
-use of_dma_xlate_by_chan_id.
Changes compared to v1:
-mian revised file, 8250_mtk_dma.c
--parameters renamed for standard
--remove atomic operation

Long Cheng (2):
  dmaengine: 8250_mtk_dma: add Mediatek uart DMA support
  arm: dts: mt2701: add uart APDMA to device tree

 arch/arm64/boot/dts/mediatek/mt2712e.dtsi |   50 ++
 drivers/dma/mediatek/8250_mtk_dma.c   |  847 +
 drivers/dma/mediatek/Kconfig  |   11 +
 drivers/dma/mediatek/Makefile |1 +
 4 files changed, 909 insertions(+)
 create mode 100644 drivers/dma/mediatek/8250_mtk_dma.c

-- 
1.7.9.5

[PATCH v3 2/2] arm: dts: mt2701: add uart APDMA to device tree

[Long Cheng]

1. add uart APDMA controller device node
2. add uart 0/1/2/3/4/5 DMA function

Signed-off-by: Long Cheng 
---
 arch/arm64/boot/dts/mediatek/mt2712e.dtsi |   50 +
 1 file changed, 50 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi 
b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index 976d92a..a59728b 100644
--- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
@@ -300,6 +300,9 @@
interrupts = ;
clocks = <_clk>, <_clk>;
clock-names = "baud", "bus";
+   dmas = < 10
+11>;
+   dma-names = "tx", "rx";
status = "disabled";
};
 
@@ -378,6 +381,38 @@
status = "disabled";
};
 
+   apdma: dma-controller@11000400 {
+   compatible = "mediatek,mt2712-uart-dma",
+"mediatek,mt6577-uart-dma";
+   reg = <0 0x11000400 0 0x80>,
+ <0 0x11000480 0 0x80>,
+ <0 0x11000500 0 0x80>,
+ <0 0x11000580 0 0x80>,
+ <0 0x11000600 0 0x80>,
+ <0 0x11000680 0 0x80>,
+ <0 0x11000700 0 0x80>,
+ <0 0x11000780 0 0x80>,
+ <0 0x11000800 0 0x80>,
+ <0 0x11000880 0 0x80>,
+ <0 0x11000900 0 0x80>,
+ <0 0x11000980 0 0x80>;
+   interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+   clocks = < CLK_PERI_AP_DMA>;
+   clock-names = "apdma";
+   #dma-cells = <1>;
+   };
+
uart0: serial@11002000 {
compatible = "mediatek,mt2712-uart",
 "mediatek,mt6577-uart";
@@ -385,6 +420,9 @@
interrupts = ;
clocks = <_clk>, <_clk>;
clock-names = "baud", "bus";
+   dmas = < 0
+1>;
+   dma-names = "tx", "rx";
status = "disabled";
};
 
@@ -395,6 +433,9 @@
interrupts = ;
clocks = <_clk>, <_clk>;
clock-names = "baud", "bus";
+   dmas = < 2
+3>;
+   dma-names = "tx", "rx";
status = "disabled";
};
 
@@ -405,6 +446,9 @@
interrupts = ;
clocks = <_clk>, <_clk>;
clock-names = "baud", "bus";
+   dmas = < 4
+5>;
+   dma-names = "tx", "rx";
status = "disabled";
};
 
@@ -415,6 +459,9 @@
interrupts = ;
clocks = <_clk>, <_clk>;
clock-names = "baud", "bus";
+   dmas = < 6
+7>;
+   dma-names = "tx", "rx";
status = "disabled";
};
 
@@ -629,6 +676,9 @@
interrupts = ;
clocks = <_clk>, <_clk>;
clock-names = "baud", "bus";
+   dmas = < 8
+9>;
+   dma-names = "tx", "rx";
status = "disabled";
};
 
-- 
1.7.9.5

[PATCH v3 0/2] add uart DMA function

[Long Cheng]

In Mediatek SOCs, the uart can support DMA function.
Base on DMA engine formwork, we add the DMA code to support uart. And put the 
code under drivers/dma.

This series contains document bindings, Kconfig to control the function enable 
or not,
device tree including interrupt and dma device node, the code of UART DM

Changes compared to v2:
-remove unimportant parameters
-instead of cookie, use APIs of virtual channel.
-use of_dma_xlate_by_chan_id.
Changes compared to v1:
-mian revised file, 8250_mtk_dma.c
--parameters renamed for standard
--remove atomic operation

Long Cheng (2):
  dmaengine: 8250_mtk_dma: add Mediatek uart DMA support
  arm: dts: mt2701: add uart APDMA to device tree

 arch/arm64/boot/dts/mediatek/mt2712e.dtsi |   50 ++
 drivers/dma/mediatek/8250_mtk_dma.c   |  847 +
 drivers/dma/mediatek/Kconfig  |   11 +
 drivers/dma/mediatek/Makefile |1 +
 4 files changed, 909 insertions(+)
 create mode 100644 drivers/dma/mediatek/8250_mtk_dma.c

-- 
1.7.9.5

[PATCH v3 2/2] arm: dts: mt2701: add uart APDMA to device tree

[Long Cheng]

1. add uart APDMA controller device node
2. add uart 0/1/2/3/4/5 DMA function

Signed-off-by: Long Cheng 
---
 arch/arm64/boot/dts/mediatek/mt2712e.dtsi |   50 +
 1 file changed, 50 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi 
b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index 976d92a..a59728b 100644
--- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
@@ -300,6 +300,9 @@
interrupts = ;
clocks = <_clk>, <_clk>;
clock-names = "baud", "bus";
+   dmas = < 10
+11>;
+   dma-names = "tx", "rx";
status = "disabled";
};
 
@@ -378,6 +381,38 @@
status = "disabled";
};
 
+   apdma: dma-controller@11000400 {
+   compatible = "mediatek,mt2712-uart-dma",
+"mediatek,mt6577-uart-dma";
+   reg = <0 0x11000400 0 0x80>,
+ <0 0x11000480 0 0x80>,
+ <0 0x11000500 0 0x80>,
+ <0 0x11000580 0 0x80>,
+ <0 0x11000600 0 0x80>,
+ <0 0x11000680 0 0x80>,
+ <0 0x11000700 0 0x80>,
+ <0 0x11000780 0 0x80>,
+ <0 0x11000800 0 0x80>,
+ <0 0x11000880 0 0x80>,
+ <0 0x11000900 0 0x80>,
+ <0 0x11000980 0 0x80>;
+   interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+   clocks = < CLK_PERI_AP_DMA>;
+   clock-names = "apdma";
+   #dma-cells = <1>;
+   };
+
uart0: serial@11002000 {
compatible = "mediatek,mt2712-uart",
 "mediatek,mt6577-uart";
@@ -385,6 +420,9 @@
interrupts = ;
clocks = <_clk>, <_clk>;
clock-names = "baud", "bus";
+   dmas = < 0
+1>;
+   dma-names = "tx", "rx";
status = "disabled";
};
 
@@ -395,6 +433,9 @@
interrupts = ;
clocks = <_clk>, <_clk>;
clock-names = "baud", "bus";
+   dmas = < 2
+3>;
+   dma-names = "tx", "rx";
status = "disabled";
};
 
@@ -405,6 +446,9 @@
interrupts = ;
clocks = <_clk>, <_clk>;
clock-names = "baud", "bus";
+   dmas = < 4
+5>;
+   dma-names = "tx", "rx";
status = "disabled";
};
 
@@ -415,6 +459,9 @@
interrupts = ;
clocks = <_clk>, <_clk>;
clock-names = "baud", "bus";
+   dmas = < 6
+7>;
+   dma-names = "tx", "rx";
status = "disabled";
};
 
@@ -629,6 +676,9 @@
interrupts = ;
clocks = <_clk>, <_clk>;
clock-names = "baud", "bus";
+   dmas = < 8
+9>;
+   dma-names = "tx", "rx";
status = "disabled";
};
 
-- 
1.7.9.5

Re: [PATCH v2 0/2] mtd: rawnand: denali: clean-up unnecessary hook and device reset

[Miquel Raynal]

Hi Masahiro,

Masahiro Yamada  wrote on Wed, 28 Nov
2018 14:27:35 +0900:

> I sent this series on September,
> and Miquel replied this series was applied:
> http://patchwork.ozlabs.org/patch/967242/
> 
> But, It turned out not applied.
> 
> I rebased it and resending now.
> 
> 
> Masahiro Yamada (2):
>   mtd: rawnand: denali: remove ->dev_ready() hook
>   mtd: rawnand: denali: remove denali_reset_banks()
> 
>  drivers/mtd/nand/raw/denali.c | 52 
> +--
>  1 file changed, 1 insertion(+), 51 deletions(-)
> 

I don't know how I missed those. Sorry for that, they are now applied
on nand/next.


Thanks,
Miquèl

Re: [PATCH v6 0/8] AXP8x3 AC and battery power supply support

[Chen-Yu Tsai]

On Fri, Dec 7, 2018 at 3:28 PM Lee Jones  wrote:
>
> On Wed, 05 Dec 2018, Sebastian Reichel wrote:
>
> > Hi,
> >
> > On Fri, Nov 30, 2018 at 04:31:28PM +0800, Chen-Yu Tsai wrote:
> > > On Wed, Nov 21, 2018 at 1:52 AM Oskari Lemmela  wrote:
> > > >
> > > > AXP813 AC power supply support with input current and
> > > > voltage limiting support.
> > > >
> > > > AXP803 AC and battery power supply support.
> > > >
> > > > Changes in v6:
> > > > * Collected tags
> > > > * Rebase to master
> > > > * Dropped AXP803 compatible patches
> > > >
> > > > Changes in v5:
> > > > * Return correct input current limit for values 0x6 and 0x7
> > > > * Add specific compatibles for AXP803
> > > > * Change commit messages
> > > > * Add Vasily Khoruzhick Pinebook DTS patch
> > > >
> > > > Changes in v4:
> > > > * Change order of axp20x-gpio in axp20x.c
> > > > * Fix indentation and spaces to tabs in axp20x.c
> > > >
> > > > Changes in v3:
> > > > * Reorder ac_power_supply DT node
> > > > * Rename axp20x_ac_power_set_property function
> > > > * Split mfd commit
> > > >
> > > > Changes in v2:
> > > > * Reuse axp813 compatibles for axp803
> > > > * Refactor axp20x_ac_power.c
> > > >
> > > >
> > > > Oskari Lemmela (7):
> > > >   dt-bindings: power: supply: axp20x: add AXP813 AC power DT binding
> > > >   ARM: dts: axp81x: add AC power supply subnode
> > > >   arm64: dts: allwinner: axp803: add AC and battery power supplies
> > > >   arm64: dts: allwinner: a64: sopine-baseboard: enable power supplies
> > > >   power: supply: add AC power supply driver for AXP813
> > > >   mfd: axp20x: Add AC power supply cell for AXP813
> > > >   mfd: axp20x: Add supported cells for AXP803
> > > >
> > > > Vasily Khoruzhick (1):
> > > >   arm64: dts: allwinner: a64: pinebook: enable power supplies
> > >
> > > Since this series has been fully reviewed, and the devices it
> > > adds/enables aren't critical, i.e. won't cause the system to fail
> > > if the drivers are missing, I've merged the dts patches for 4.21.
> > >
> > > Hopefully Sebastian and Lee will get around to merging the driver
> > > patches.
> >
> > I queued the power-supply driver changes and prepared a signed
> > immutable tag for Lee:
> >
> > The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
> >
> >   Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
> >
> > are available in the Git repository at:
> >
> >   
> > ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git
> >  tags/psy-mfd-axp813-immutable-for-v4.21-signed
> >
> > for you to fetch changes up to 7693b5643fd2d682de90733b67fc8032b9646911:
> >
> >   power: supply: add AC power supply driver for AXP813 (2018-12-05 18:49:32 
> > +0100)
> >
> > 
> > Immutable branch between mfd and power-supply for driver
> > changes related to axp813.
> >
> > Signed-off-by: Sebastian Reichel 
> >
> > 
> > Oskari Lemmela (2):
> >   dt-bindings: power: supply: axp20x: add AXP813 AC power DT binding
> >   power: supply: add AC power supply driver for AXP813
> >
> >  .../bindings/power/supply/axp20x_ac_power.txt  |  3 +
> >  drivers/power/supply/axp20x_ac_power.c | 94 
> > ++
> >  include/linux/mfd/axp20x.h |  1 +
> >  3 files changed, 98 insertions(+)
>
> What patches are left now?  Just 7 and 8?

That's right. If you could merge them, that'd be great.
Thanks Lee.

ChenYu

Re: [PATCH v2 0/2] mtd: rawnand: denali: clean-up unnecessary hook and device reset

[Miquel Raynal]

Hi Masahiro,

Masahiro Yamada  wrote on Wed, 28 Nov
2018 14:27:35 +0900:

> I sent this series on September,
> and Miquel replied this series was applied:
> http://patchwork.ozlabs.org/patch/967242/
> 
> But, It turned out not applied.
> 
> I rebased it and resending now.
> 
> 
> Masahiro Yamada (2):
>   mtd: rawnand: denali: remove ->dev_ready() hook
>   mtd: rawnand: denali: remove denali_reset_banks()
> 
>  drivers/mtd/nand/raw/denali.c | 52 
> +--
>  1 file changed, 1 insertion(+), 51 deletions(-)
> 

I don't know how I missed those. Sorry for that, they are now applied
on nand/next.


Thanks,
Miquèl

Re: [PATCH v6 0/8] AXP8x3 AC and battery power supply support

[Chen-Yu Tsai]

On Fri, Dec 7, 2018 at 3:28 PM Lee Jones  wrote:
>
> On Wed, 05 Dec 2018, Sebastian Reichel wrote:
>
> > Hi,
> >
> > On Fri, Nov 30, 2018 at 04:31:28PM +0800, Chen-Yu Tsai wrote:
> > > On Wed, Nov 21, 2018 at 1:52 AM Oskari Lemmela  wrote:
> > > >
> > > > AXP813 AC power supply support with input current and
> > > > voltage limiting support.
> > > >
> > > > AXP803 AC and battery power supply support.
> > > >
> > > > Changes in v6:
> > > > * Collected tags
> > > > * Rebase to master
> > > > * Dropped AXP803 compatible patches
> > > >
> > > > Changes in v5:
> > > > * Return correct input current limit for values 0x6 and 0x7
> > > > * Add specific compatibles for AXP803
> > > > * Change commit messages
> > > > * Add Vasily Khoruzhick Pinebook DTS patch
> > > >
> > > > Changes in v4:
> > > > * Change order of axp20x-gpio in axp20x.c
> > > > * Fix indentation and spaces to tabs in axp20x.c
> > > >
> > > > Changes in v3:
> > > > * Reorder ac_power_supply DT node
> > > > * Rename axp20x_ac_power_set_property function
> > > > * Split mfd commit
> > > >
> > > > Changes in v2:
> > > > * Reuse axp813 compatibles for axp803
> > > > * Refactor axp20x_ac_power.c
> > > >
> > > >
> > > > Oskari Lemmela (7):
> > > >   dt-bindings: power: supply: axp20x: add AXP813 AC power DT binding
> > > >   ARM: dts: axp81x: add AC power supply subnode
> > > >   arm64: dts: allwinner: axp803: add AC and battery power supplies
> > > >   arm64: dts: allwinner: a64: sopine-baseboard: enable power supplies
> > > >   power: supply: add AC power supply driver for AXP813
> > > >   mfd: axp20x: Add AC power supply cell for AXP813
> > > >   mfd: axp20x: Add supported cells for AXP803
> > > >
> > > > Vasily Khoruzhick (1):
> > > >   arm64: dts: allwinner: a64: pinebook: enable power supplies
> > >
> > > Since this series has been fully reviewed, and the devices it
> > > adds/enables aren't critical, i.e. won't cause the system to fail
> > > if the drivers are missing, I've merged the dts patches for 4.21.
> > >
> > > Hopefully Sebastian and Lee will get around to merging the driver
> > > patches.
> >
> > I queued the power-supply driver changes and prepared a signed
> > immutable tag for Lee:
> >
> > The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
> >
> >   Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
> >
> > are available in the Git repository at:
> >
> >   
> > ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git
> >  tags/psy-mfd-axp813-immutable-for-v4.21-signed
> >
> > for you to fetch changes up to 7693b5643fd2d682de90733b67fc8032b9646911:
> >
> >   power: supply: add AC power supply driver for AXP813 (2018-12-05 18:49:32 
> > +0100)
> >
> > 
> > Immutable branch between mfd and power-supply for driver
> > changes related to axp813.
> >
> > Signed-off-by: Sebastian Reichel 
> >
> > 
> > Oskari Lemmela (2):
> >   dt-bindings: power: supply: axp20x: add AXP813 AC power DT binding
> >   power: supply: add AC power supply driver for AXP813
> >
> >  .../bindings/power/supply/axp20x_ac_power.txt  |  3 +
> >  drivers/power/supply/axp20x_ac_power.c | 94 
> > ++
> >  include/linux/mfd/axp20x.h |  1 +
> >  3 files changed, 98 insertions(+)
>
> What patches are left now?  Just 7 and 8?

That's right. If you could merge them, that'd be great.
Thanks Lee.

ChenYu

Re: MADV_HUGEPAGE vs. NUMA semantic (was: Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression)

[Michal Hocko]

On Thu 06-12-18 15:49:04, David Rientjes wrote:
> On Thu, 6 Dec 2018, Michal Hocko wrote:
> 
> > MADV_HUGEPAGE changes the picture because the caller expressed a need
> > for THP and is willing to go extra mile to get it. That involves
> > allocation latency and as of now also a potential remote access. We do
> > not have complete agreement on the later but the prevailing argument is
> > that any strong NUMA locality is just reinventing node-reclaim story
> > again or makes THP success rate down the toilet (to quote Mel). I agree
> > that we do not want to fallback to a remote node overeagerly. I believe
> > that something like the below would be sensible
> > 1) THP on a local node with compaction not giving up too early
> > 2) THP on a remote node in NOWAIT mode - so no direct
> >compaction/reclaim (trigger kswapd/kcompactd only for
> >defrag=defer+madvise)
> > 3) fallback to the base page allocation
> > 
> 
> I disagree that MADV_HUGEPAGE should take on any new semantic that 
> overrides the preference of node local memory for a hugepage, which is the 
> nearly four year behavior.  The order of MADV_HUGEPAGE preferences listed 
> above would cause current users to regress who rely on local small page 
> fallback rather than remote hugepages because the access latency is much 
> better.  I think the preference of remote hugepages over local small pages 
> needs to be expressed differently to prevent regression.

Such a model would be broken. It doesn't provide consistent semantic and
leads to surprising results. MADV_HUGEPAGE with local node binding will
not prevent remote base pages to be used and you are back to square one.

It has been a huge mistake to merge your __GFP_THISNODE patch back then
in 4.1. Especially with an absolute lack of numbers for a variety of
workloads. I still believe we can do better, offer a sane mem policy to
help workloads with higher locality demands but it is outright wrong
to confalte demand for THP with the locality semantic.

If this is absolutely no go then we need a MADV_HUGEPAGE_SANE...

-- 
Michal Hocko
SUSE Labs

Re: MADV_HUGEPAGE vs. NUMA semantic (was: Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression)

[Michal Hocko]

On Thu 06-12-18 15:49:04, David Rientjes wrote:
> On Thu, 6 Dec 2018, Michal Hocko wrote:
> 
> > MADV_HUGEPAGE changes the picture because the caller expressed a need
> > for THP and is willing to go extra mile to get it. That involves
> > allocation latency and as of now also a potential remote access. We do
> > not have complete agreement on the later but the prevailing argument is
> > that any strong NUMA locality is just reinventing node-reclaim story
> > again or makes THP success rate down the toilet (to quote Mel). I agree
> > that we do not want to fallback to a remote node overeagerly. I believe
> > that something like the below would be sensible
> > 1) THP on a local node with compaction not giving up too early
> > 2) THP on a remote node in NOWAIT mode - so no direct
> >compaction/reclaim (trigger kswapd/kcompactd only for
> >defrag=defer+madvise)
> > 3) fallback to the base page allocation
> > 
> 
> I disagree that MADV_HUGEPAGE should take on any new semantic that 
> overrides the preference of node local memory for a hugepage, which is the 
> nearly four year behavior.  The order of MADV_HUGEPAGE preferences listed 
> above would cause current users to regress who rely on local small page 
> fallback rather than remote hugepages because the access latency is much 
> better.  I think the preference of remote hugepages over local small pages 
> needs to be expressed differently to prevent regression.

Such a model would be broken. It doesn't provide consistent semantic and
leads to surprising results. MADV_HUGEPAGE with local node binding will
not prevent remote base pages to be used and you are back to square one.

It has been a huge mistake to merge your __GFP_THISNODE patch back then
in 4.1. Especially with an absolute lack of numbers for a variety of
workloads. I still believe we can do better, offer a sane mem policy to
help workloads with higher locality demands but it is outright wrong
to confalte demand for THP with the locality semantic.

If this is absolutely no go then we need a MADV_HUGEPAGE_SANE...

-- 
Michal Hocko
SUSE Labs

[PATCH 1/1] virtio: remove deprecated VIRTIO_PCI_CONFIG()

[Dongli Zhang]

VIRTIO_PCI_CONFIG() is deprecated. Use VIRTIO_PCI_CONFIG_OFF() instead.

Signed-off-by: Dongli Zhang 
---
 drivers/virtio/virtio_pci_legacy.c | 6 --
 include/uapi/linux/virtio_pci.h| 2 --
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/virtio/virtio_pci_legacy.c 
b/drivers/virtio/virtio_pci_legacy.c
index de062fb..eff9ddc 100644
--- a/drivers/virtio/virtio_pci_legacy.c
+++ b/drivers/virtio/virtio_pci_legacy.c
@@ -52,7 +52,8 @@ static void vp_get(struct virtio_device *vdev, unsigned 
offset,
 {
struct virtio_pci_device *vp_dev = to_vp_device(vdev);
void __iomem *ioaddr = vp_dev->ioaddr +
-   VIRTIO_PCI_CONFIG(vp_dev) + offset;
+   VIRTIO_PCI_CONFIG_OFF(vp_dev->msix_enabled) +
+   offset;
u8 *ptr = buf;
int i;
 
@@ -67,7 +68,8 @@ static void vp_set(struct virtio_device *vdev, unsigned 
offset,
 {
struct virtio_pci_device *vp_dev = to_vp_device(vdev);
void __iomem *ioaddr = vp_dev->ioaddr +
-   VIRTIO_PCI_CONFIG(vp_dev) + offset;
+   VIRTIO_PCI_CONFIG_OFF(vp_dev->msix_enabled) +
+   offset;
const u8 *ptr = buf;
int i;
 
diff --git a/include/uapi/linux/virtio_pci.h b/include/uapi/linux/virtio_pci.h
index 90007a1..2070232 100644
--- a/include/uapi/linux/virtio_pci.h
+++ b/include/uapi/linux/virtio_pci.h
@@ -78,8 +78,6 @@
 /* The remaining space is defined by each driver as the per-driver
  * configuration space */
 #define VIRTIO_PCI_CONFIG_OFF(msix_enabled)((msix_enabled) ? 24 : 20)
-/* Deprecated: please use VIRTIO_PCI_CONFIG_OFF instead */
-#define VIRTIO_PCI_CONFIG(dev) VIRTIO_PCI_CONFIG_OFF((dev)->msix_enabled)
 
 /* Virtio ABI version, this must match exactly */
 #define VIRTIO_PCI_ABI_VERSION 0
-- 
2.7.4

Re: [PATCH v7 0/7] Introduce STPMIC1 PMIC Driver

[Lee Jones]

On Wed, 05 Dec 2018, Pascal PAILLET-LME wrote:

> 
> pascal paillet (p.pail...@st.com) Le Mans / France
> Microcontrollers and Digital ICs Group | Application Development
> TEL: +33.(0)2.44.02.74.69 | TINA: 166 7469
> 
> Le 12/05/2018 10:36 AM, Lee Jones a écrit :
> > On Tue, 04 Dec 2018, Pascal PAILLET-LME wrote:
> >> Le 12/03/2018 08:11 AM, Lee Jones a écrit :
> >>> On Fri, 30 Nov 2018, Pascal PAILLET-LME wrote:
> >>>
>  The goal of this patch-set is to propose a driver for the STPMIC1 PMIC 
>  from
>  STMicroelectronics.
>  The STPMIC1 regulators supply power to an application processor as well 
>  as
>  to external system peripherals such as DDR, Flash memories and system
>  devices. It also features onkey button input and an hardware watchdog.
>  The STPMIC1 is controlled via I2C.
> 
>  Main driver is drivers/mfd/stpmic1 that handle I2C regmap configuration 
>  and
>  irqchip. stpmic1_regulator, stpmic1_onkey and stpmic1_wdt need stpmic1 
>  mfd
>  as parent.
> 
>  STPMIC1 MFD and regulator drivers maybe mandatory at boot time.
> 
>  Pascal Paillet (7):
>  changes in v7:
>  * rebase on regul/for-next
> 
>  dt-bindings: mfd: document stpmic1
>  mfd: stpmic1: add stpmic1 driver
>  dt-bindings: input: document stpmic1 pmic onkey
>  input: stpmic1: add stpmic1 onkey driver
>  dt-bindings: watchdog: document stpmic1 pmic watchdog
>  watchdog: stpmic1: add stpmic1 watchdog driver
>  regulator: stpmic1: fix regulator_lock usage
> 
> .../devicetree/bindings/input/st,stpmic1-onkey.txt |  28 +++
> .../devicetree/bindings/mfd/st,stpmic1.txt |  61 ++
> .../bindings/watchdog/st,stpmic1-wdt.txt   |  11 ++
> drivers/input/misc/Kconfig |  11 ++
> drivers/input/misc/Makefile|   2 +
> drivers/input/misc/stpmic1_onkey.c | 198 
>  +++
> drivers/mfd/Kconfig|  16 ++
> drivers/mfd/Makefile   |   1 +
> drivers/mfd/stpmic1.c  | 213 
>  +
> drivers/regulator/stpmic1_regulator.c  |   2 +-
> >>> Is it just Mark you're waiting on now?
> >> It is ok now, Mark has applied the patch.
> >> Evrey thing has been acked now. What is the nex step ?
> > Mark has applied patch 7?
> >
> > Why don't I see that?  Should you have removed it from this set?
> Hi Lee, I have received an email from Mark telliing that the regulator 
> patch is applied on
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git  
> 
> I can see it on the branch regul/for-next.

Mark,

Does your patch tracker only reply to the author?

Any reason why I don't see it?

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

Re: [PATCH v7 0/7] Introduce STPMIC1 PMIC Driver

[Lee Jones]

On Wed, 05 Dec 2018, Pascal PAILLET-LME wrote:

> 
> pascal paillet (p.pail...@st.com) Le Mans / France
> Microcontrollers and Digital ICs Group | Application Development
> TEL: +33.(0)2.44.02.74.69 | TINA: 166 7469
> 
> Le 12/05/2018 10:36 AM, Lee Jones a écrit :
> > On Tue, 04 Dec 2018, Pascal PAILLET-LME wrote:
> >> Le 12/03/2018 08:11 AM, Lee Jones a écrit :
> >>> On Fri, 30 Nov 2018, Pascal PAILLET-LME wrote:
> >>>
>  The goal of this patch-set is to propose a driver for the STPMIC1 PMIC 
>  from
>  STMicroelectronics.
>  The STPMIC1 regulators supply power to an application processor as well 
>  as
>  to external system peripherals such as DDR, Flash memories and system
>  devices. It also features onkey button input and an hardware watchdog.
>  The STPMIC1 is controlled via I2C.
> 
>  Main driver is drivers/mfd/stpmic1 that handle I2C regmap configuration 
>  and
>  irqchip. stpmic1_regulator, stpmic1_onkey and stpmic1_wdt need stpmic1 
>  mfd
>  as parent.
> 
>  STPMIC1 MFD and regulator drivers maybe mandatory at boot time.
> 
>  Pascal Paillet (7):
>  changes in v7:
>  * rebase on regul/for-next
> 
>  dt-bindings: mfd: document stpmic1
>  mfd: stpmic1: add stpmic1 driver
>  dt-bindings: input: document stpmic1 pmic onkey
>  input: stpmic1: add stpmic1 onkey driver
>  dt-bindings: watchdog: document stpmic1 pmic watchdog
>  watchdog: stpmic1: add stpmic1 watchdog driver
>  regulator: stpmic1: fix regulator_lock usage
> 
> .../devicetree/bindings/input/st,stpmic1-onkey.txt |  28 +++
> .../devicetree/bindings/mfd/st,stpmic1.txt |  61 ++
> .../bindings/watchdog/st,stpmic1-wdt.txt   |  11 ++
> drivers/input/misc/Kconfig |  11 ++
> drivers/input/misc/Makefile|   2 +
> drivers/input/misc/stpmic1_onkey.c | 198 
>  +++
> drivers/mfd/Kconfig|  16 ++
> drivers/mfd/Makefile   |   1 +
> drivers/mfd/stpmic1.c  | 213 
>  +
> drivers/regulator/stpmic1_regulator.c  |   2 +-
> >>> Is it just Mark you're waiting on now?
> >> It is ok now, Mark has applied the patch.
> >> Evrey thing has been acked now. What is the nex step ?
> > Mark has applied patch 7?
> >
> > Why don't I see that?  Should you have removed it from this set?
> Hi Lee, I have received an email from Mark telliing that the regulator 
> patch is applied on
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git  
> 
> I can see it on the branch regul/for-next.

Mark,

Does your patch tracker only reply to the author?

Any reason why I don't see it?

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

Re: [PATCH v6 0/8] AXP8x3 AC and battery power supply support

[Lee Jones]

On Wed, 05 Dec 2018, Sebastian Reichel wrote:

> Hi,
> 
> On Fri, Nov 30, 2018 at 04:31:28PM +0800, Chen-Yu Tsai wrote:
> > On Wed, Nov 21, 2018 at 1:52 AM Oskari Lemmela  wrote:
> > >
> > > AXP813 AC power supply support with input current and
> > > voltage limiting support.
> > >
> > > AXP803 AC and battery power supply support.
> > >
> > > Changes in v6:
> > > * Collected tags
> > > * Rebase to master
> > > * Dropped AXP803 compatible patches
> > >
> > > Changes in v5:
> > > * Return correct input current limit for values 0x6 and 0x7
> > > * Add specific compatibles for AXP803
> > > * Change commit messages
> > > * Add Vasily Khoruzhick Pinebook DTS patch
> > >
> > > Changes in v4:
> > > * Change order of axp20x-gpio in axp20x.c
> > > * Fix indentation and spaces to tabs in axp20x.c
> > >
> > > Changes in v3:
> > > * Reorder ac_power_supply DT node
> > > * Rename axp20x_ac_power_set_property function
> > > * Split mfd commit
> > >
> > > Changes in v2:
> > > * Reuse axp813 compatibles for axp803
> > > * Refactor axp20x_ac_power.c
> > >
> > >
> > > Oskari Lemmela (7):
> > >   dt-bindings: power: supply: axp20x: add AXP813 AC power DT binding
> > >   ARM: dts: axp81x: add AC power supply subnode
> > >   arm64: dts: allwinner: axp803: add AC and battery power supplies
> > >   arm64: dts: allwinner: a64: sopine-baseboard: enable power supplies
> > >   power: supply: add AC power supply driver for AXP813
> > >   mfd: axp20x: Add AC power supply cell for AXP813
> > >   mfd: axp20x: Add supported cells for AXP803
> > >
> > > Vasily Khoruzhick (1):
> > >   arm64: dts: allwinner: a64: pinebook: enable power supplies
> > 
> > Since this series has been fully reviewed, and the devices it
> > adds/enables aren't critical, i.e. won't cause the system to fail
> > if the drivers are missing, I've merged the dts patches for 4.21.
> > 
> > Hopefully Sebastian and Lee will get around to merging the driver
> > patches.
> 
> I queued the power-supply driver changes and prepared a signed
> immutable tag for Lee:
> 
> The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
> 
>   Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
> 
> are available in the Git repository at:
> 
>   
> ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git
>  tags/psy-mfd-axp813-immutable-for-v4.21-signed
> 
> for you to fetch changes up to 7693b5643fd2d682de90733b67fc8032b9646911:
> 
>   power: supply: add AC power supply driver for AXP813 (2018-12-05 18:49:32 
> +0100)
> 
> 
> Immutable branch between mfd and power-supply for driver
> changes related to axp813.
> 
> Signed-off-by: Sebastian Reichel 
> 
> 
> Oskari Lemmela (2):
>   dt-bindings: power: supply: axp20x: add AXP813 AC power DT binding
>   power: supply: add AC power supply driver for AXP813
> 
>  .../bindings/power/supply/axp20x_ac_power.txt  |  3 +
>  drivers/power/supply/axp20x_ac_power.c | 94 
> ++
>  include/linux/mfd/axp20x.h |  1 +
>  3 files changed, 98 insertions(+)

What patches are left now?  Just 7 and 8?

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

Re: [PATCH v6 0/8] AXP8x3 AC and battery power supply support

[Lee Jones]

On Wed, 05 Dec 2018, Sebastian Reichel wrote:

> Hi,
> 
> On Fri, Nov 30, 2018 at 04:31:28PM +0800, Chen-Yu Tsai wrote:
> > On Wed, Nov 21, 2018 at 1:52 AM Oskari Lemmela  wrote:
> > >
> > > AXP813 AC power supply support with input current and
> > > voltage limiting support.
> > >
> > > AXP803 AC and battery power supply support.
> > >
> > > Changes in v6:
> > > * Collected tags
> > > * Rebase to master
> > > * Dropped AXP803 compatible patches
> > >
> > > Changes in v5:
> > > * Return correct input current limit for values 0x6 and 0x7
> > > * Add specific compatibles for AXP803
> > > * Change commit messages
> > > * Add Vasily Khoruzhick Pinebook DTS patch
> > >
> > > Changes in v4:
> > > * Change order of axp20x-gpio in axp20x.c
> > > * Fix indentation and spaces to tabs in axp20x.c
> > >
> > > Changes in v3:
> > > * Reorder ac_power_supply DT node
> > > * Rename axp20x_ac_power_set_property function
> > > * Split mfd commit
> > >
> > > Changes in v2:
> > > * Reuse axp813 compatibles for axp803
> > > * Refactor axp20x_ac_power.c
> > >
> > >
> > > Oskari Lemmela (7):
> > >   dt-bindings: power: supply: axp20x: add AXP813 AC power DT binding
> > >   ARM: dts: axp81x: add AC power supply subnode
> > >   arm64: dts: allwinner: axp803: add AC and battery power supplies
> > >   arm64: dts: allwinner: a64: sopine-baseboard: enable power supplies
> > >   power: supply: add AC power supply driver for AXP813
> > >   mfd: axp20x: Add AC power supply cell for AXP813
> > >   mfd: axp20x: Add supported cells for AXP803
> > >
> > > Vasily Khoruzhick (1):
> > >   arm64: dts: allwinner: a64: pinebook: enable power supplies
> > 
> > Since this series has been fully reviewed, and the devices it
> > adds/enables aren't critical, i.e. won't cause the system to fail
> > if the drivers are missing, I've merged the dts patches for 4.21.
> > 
> > Hopefully Sebastian and Lee will get around to merging the driver
> > patches.
> 
> I queued the power-supply driver changes and prepared a signed
> immutable tag for Lee:
> 
> The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
> 
>   Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
> 
> are available in the Git repository at:
> 
>   
> ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git
>  tags/psy-mfd-axp813-immutable-for-v4.21-signed
> 
> for you to fetch changes up to 7693b5643fd2d682de90733b67fc8032b9646911:
> 
>   power: supply: add AC power supply driver for AXP813 (2018-12-05 18:49:32 
> +0100)
> 
> 
> Immutable branch between mfd and power-supply for driver
> changes related to axp813.
> 
> Signed-off-by: Sebastian Reichel 
> 
> 
> Oskari Lemmela (2):
>   dt-bindings: power: supply: axp20x: add AXP813 AC power DT binding
>   power: supply: add AC power supply driver for AXP813
> 
>  .../bindings/power/supply/axp20x_ac_power.txt  |  3 +
>  drivers/power/supply/axp20x_ac_power.c | 94 
> ++
>  include/linux/mfd/axp20x.h |  1 +
>  3 files changed, 98 insertions(+)

What patches are left now?  Just 7 and 8?

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

Re: [PATCH v4 0/5] powerpc: system call table generation support

[Satheesh Rajendran]

On Fri, Dec 07, 2018 at 11:41:35AM +0530, Firoz Khan wrote:
> The purpose of this patch series is, we can easily
> add/modify/delete system call table support by cha-
> nging entry in syscall.tbl file instead of manually
> changing many files. The other goal is to unify the 
> system call table generation support implementation 
> across all the architectures. 
> 
> The system call tables are in different format in 
> all architecture. It will be difficult to manually
> add, modify or delete the system calls in the resp-
> ective files manually. To make it easy by keeping a 
> script and which'll generate uapi header file and 
> syscall table file.
> 
> syscall.tbl contains the list of available system 
> calls along with system call number and correspond-
> ing entry point. Add a new system call in this arch-
> itecture will be possible by adding new entry in 
> the syscall.tbl file.
> 
> Adding a new table entry consisting of:
> - System call number.
> - ABI.
> - System call name.
> - Entry point name.
>   - Compat entry name, if required.
>   - spu entry name, if required.
> 
> ARM, s390 and x86 architecuture does exist the sim-
> ilar support. I leverage their implementation to 
> come up with a generic solution.
> 
> I have done the same support for work for alpha, 
> ia64, m68k, microblaze, mips, parisc, sh, sparc, 
> and xtensa. Below mentioned git repository contains
> more details about the workflow.
> 
> https://github.com/frzkhn/system_call_table_generator/
> 
> Finally, this is the ground work to solve the Y2038
> issue. We need to add two dozen of system calls to 
> solve Y2038 issue. So this patch series will help to
> add new system calls easily by adding new entry in the
> syscall.tbl.
> 
> Changes since v3:
>  - split compat syscall table out from native table.
>  - modified the script to add new line in the generated
>file.
Hi Firoz,

This version(v4) booted fine in IBM Power8 box.
Compiled with 'ppc64le_defconfig' aginst 
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?h=merge=a26b21082959cee3075b3edb7ef23071c7e0b09a

Reference failure v3 version: 
https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-November/182110.html

Regards,
-Satheesh.
> 
> Changes since v2:
>  - modified/optimized the syscall.tbl to avoid duplicate
>for the spu entries.
>  - updated the syscalltbl.sh to meet the above point.
> 
> Changes since v1:
>  - optimized/updated the syscall table generation 
>scripts.
>  - fixed all mixed indentation issues in syscall.tbl.
>  - added "comments" in syscall_*.tbl.
>  - changed from generic-y to generated-y in Kbuild.
> 
> Firoz Khan (5):
>   powerpc: add __NR_syscalls along with NR_syscalls
>   powerpc: move macro definition from asm/systbl.h
>   powerpc: add system call table generation support
>   powerpc: split compat syscall table out from native table
>   powerpc: generate uapi header and system call table files
> 
>  arch/powerpc/Makefile   |   3 +
>  arch/powerpc/include/asm/Kbuild |   4 +
>  arch/powerpc/include/asm/syscall.h  |   3 +-
>  arch/powerpc/include/asm/systbl.h   | 396 --
>  arch/powerpc/include/asm/unistd.h   |   3 +-
>  arch/powerpc/include/uapi/asm/Kbuild|   2 +
>  arch/powerpc/include/uapi/asm/unistd.h  | 389 +
>  arch/powerpc/kernel/Makefile|  10 -
>  arch/powerpc/kernel/entry_64.S  |   7 +-
>  arch/powerpc/kernel/syscalls/Makefile   |  63 
>  arch/powerpc/kernel/syscalls/syscall.tbl| 427 
> 
>  arch/powerpc/kernel/syscalls/syscallhdr.sh  |  37 +++
>  arch/powerpc/kernel/syscalls/syscalltbl.sh  |  36 +++
>  arch/powerpc/kernel/systbl.S|  40 ++-
>  arch/powerpc/kernel/systbl_chk.c|  60 
>  arch/powerpc/kernel/vdso.c  |   7 +-
>  arch/powerpc/platforms/cell/spu_callbacks.c |  17 +-
>  17 files changed, 606 insertions(+), 898 deletions(-)
>  delete mode 100644 arch/powerpc/include/asm/systbl.h
>  create mode 100644 arch/powerpc/kernel/syscalls/Makefile
>  create mode 100644 arch/powerpc/kernel/syscalls/syscall.tbl
>  create mode 100644 arch/powerpc/kernel/syscalls/syscallhdr.sh
>  create mode 100644 arch/powerpc/kernel/syscalls/syscalltbl.sh
>  delete mode 100644 arch/powerpc/kernel/systbl_chk.c
> 
> -- 
> 1.9.1
> 

Re: [PATCH v5 1/3] mm: Add support for kmem caches in DMA32 zone

[Vlastimil Babka]

On 12/7/18 7:16 AM, Nicolas Boichat wrote:
> IOMMUs using ARMv7 short-descriptor format require page tables
> to be allocated within the first 4GB of RAM, even on 64-bit systems.
> On arm64, this is done by passing GFP_DMA32 flag to memory allocation
> functions.
> 
> For IOMMU L2 tables that only take 1KB, it would be a waste to allocate
> a full page using get_free_pages, so we considered 3 approaches:
>  1. This patch, adding support for GFP_DMA32 slab caches.
>  2. genalloc, which requires pre-allocating the maximum number of L2
> page tables (4096, so 4MB of memory).
>  3. page_frag, which is not very memory-efficient as it is unable
> to reuse freed fragments until the whole page is freed.
> 
> This change makes it possible to create a custom cache in DMA32 zone
> using kmem_cache_create, then allocate memory using kmem_cache_alloc.
> 
> We do not create a DMA32 kmalloc cache array, as there are currently
> no users of kmalloc(..., GFP_DMA32). These calls will continue to
> trigger a warning, as we keep GFP_DMA32 in GFP_SLAB_BUG_MASK.
> 
> This implies that calls to kmem_cache_*alloc on a SLAB_CACHE_DMA32
> kmem_cache must _not_ use GFP_DMA32 (it is anyway redundant and
> unnecessary).
> 
> Signed-off-by: Nicolas Boichat 

Acked-by: Vlastimil Babka 

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

[Lee Jones]

On Thu, 06 Dec 2018, Cheng-yi Chiang wrote:

> On Wed, Dec 5, 2018 at 7:34 PM Lee Jones  wrote:
> >
> > On Wed, 05 Dec 2018, Lee Jones wrote:
> >
> > > On Wed, 05 Dec 2018, Cheng-yi Chiang wrote:
> > >
> > > > Hi Lee,
> > > >
> > > > I tried to apply this patch based on
> > > > for-mfd-next branch of mfd tree (
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git )
> > > > Then, I tried to compile all modules by
> > > >
> > > >  ARCH=x86_64 make allyesconfig
> > > >  ARCH=x86_64 make -j64
> > > >
> > > > There was no error.
> > > > Could you please let me know what was the error when you failed to
> > > > apply this patch ?
> > >
> > > Doesn't work for me.
> > >
> > > lee@host:~/projects/kernel [for-mfd-next]$ formfdnext
> > > Applying: mfd: cros_ec: Add commands to control codec
> > > error: sha1 information is lacking or useless 
> > > (include/linux/mfd/cros_ec_commands.h).
> > > error: could not build fake ancestor
> > > Patch failed at 0001 mfd: cros_ec: Add commands to control codec
> > > Use 'git am --show-current-patch' to see the failed patch
> > > When you have resolved this problem, run "git am --continue".
> > > If you prefer to skip this patch, run "git am --skip" instead.
> > > To restore the original branch and stop patching, run "git am --abort".
> >
> > Not that the following lines (as seen in your patch) are not present
> > in the Mainline kernel.
> >
> > > @@ -4077,6 +4077,100 @@ struct __ec_align1 
> > > ec_response_i2c_passthru_protect {
> > >   uint8_t status; /* Status flags (0: unlocked, 1: locked) */
> > >  };
> >
> > Do you have other patches applied to your tree?
> 
> Hi Lee,
> Sorry, I see the problem.
> I was using git am -3 which solves the conflict by itself.

That's what I use, but it still had issues.

Git is probably using a previous resolution in your case.

> I will resend a patch based on your for-mfd-next branch so we can keep
> the patch clean.
> Thanks for your time.

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

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

[Lee Jones]

On Thu, 06 Dec 2018, Cheng-yi Chiang wrote:

> On Wed, Dec 5, 2018 at 7:34 PM Lee Jones  wrote:
> >
> > On Wed, 05 Dec 2018, Lee Jones wrote:
> >
> > > On Wed, 05 Dec 2018, Cheng-yi Chiang wrote:
> > >
> > > > Hi Lee,
> > > >
> > > > I tried to apply this patch based on
> > > > for-mfd-next branch of mfd tree (
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git )
> > > > Then, I tried to compile all modules by
> > > >
> > > >  ARCH=x86_64 make allyesconfig
> > > >  ARCH=x86_64 make -j64
> > > >
> > > > There was no error.
> > > > Could you please let me know what was the error when you failed to
> > > > apply this patch ?
> > >
> > > Doesn't work for me.
> > >
> > > lee@host:~/projects/kernel [for-mfd-next]$ formfdnext
> > > Applying: mfd: cros_ec: Add commands to control codec
> > > error: sha1 information is lacking or useless 
> > > (include/linux/mfd/cros_ec_commands.h).
> > > error: could not build fake ancestor
> > > Patch failed at 0001 mfd: cros_ec: Add commands to control codec
> > > Use 'git am --show-current-patch' to see the failed patch
> > > When you have resolved this problem, run "git am --continue".
> > > If you prefer to skip this patch, run "git am --skip" instead.
> > > To restore the original branch and stop patching, run "git am --abort".
> >
> > Not that the following lines (as seen in your patch) are not present
> > in the Mainline kernel.
> >
> > > @@ -4077,6 +4077,100 @@ struct __ec_align1 
> > > ec_response_i2c_passthru_protect {
> > >   uint8_t status; /* Status flags (0: unlocked, 1: locked) */
> > >  };
> >
> > Do you have other patches applied to your tree?
> 
> Hi Lee,
> Sorry, I see the problem.
> I was using git am -3 which solves the conflict by itself.

That's what I use, but it still had issues.

Git is probably using a previous resolution in your case.

> I will resend a patch based on your for-mfd-next branch so we can keep
> the patch clean.
> Thanks for your time.

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

Re: [PATCH v2] tps65218: Use devm_regmap_add_irq_chip and clean up error path in probe

[Ladislav Michl]

On Fri, Dec 07, 2018 at 06:19:48AM +0530, Keerthy wrote:
> Use devm_regmap_add_irq_chip and clean up error path in probe.
> Hence clean up the probe error path and the remove function.
> 
> Reported-by: Christian Hohnstaedt 
> Signed-off-by: Keerthy 
> ---
> 
> Changes in v2:
> 
>   * Cleaned up remove function as well.

v3: Remove remove function? :)

>  drivers/mfd/tps65218.c | 18 +++---
>  1 file changed, 3 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
> index 910f569..d2d4e3a 100644
> --- a/drivers/mfd/tps65218.c
> +++ b/drivers/mfd/tps65218.c
> @@ -235,9 +235,9 @@ static int tps65218_probe(struct i2c_client *client,
>  
>   mutex_init(>tps_lock);
>  
> - ret = regmap_add_irq_chip(tps->regmap, tps->irq,
> - IRQF_ONESHOT, 0, _irq_chip,
> - >irq_data);
> + ret = devm_regmap_add_irq_chip(>dev, tps->regmap, tps->irq,
> +IRQF_ONESHOT, 0, _irq_chip,
> +>irq_data);
>   if (ret < 0)
>   return ret;
>  
> @@ -253,23 +253,11 @@ static int tps65218_probe(struct i2c_client *client,
> ARRAY_SIZE(tps65218_cells), NULL, 0,
> regmap_irq_get_domain(tps->irq_data));
>  
> - if (ret < 0)
> - goto err_irq;
> -
> - return 0;
> -
> -err_irq:
> - regmap_del_irq_chip(tps->irq, tps->irq_data);
> -
>   return ret;
>  }
>  
>  static int tps65218_remove(struct i2c_client *client)
>  {
> - struct tps65218 *tps = i2c_get_clientdata(client);
> -
> - regmap_del_irq_chip(tps->irq, tps->irq_data);
> -
>   return 0;
>  }
>  
> -- 
> 1.9.1

Re: [PATCH v2] tps65218: Use devm_regmap_add_irq_chip and clean up error path in probe

[Ladislav Michl]

On Fri, Dec 07, 2018 at 06:19:48AM +0530, Keerthy wrote:
> Use devm_regmap_add_irq_chip and clean up error path in probe.
> Hence clean up the probe error path and the remove function.
> 
> Reported-by: Christian Hohnstaedt 
> Signed-off-by: Keerthy 
> ---
> 
> Changes in v2:
> 
>   * Cleaned up remove function as well.

v3: Remove remove function? :)

>  drivers/mfd/tps65218.c | 18 +++---
>  1 file changed, 3 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
> index 910f569..d2d4e3a 100644
> --- a/drivers/mfd/tps65218.c
> +++ b/drivers/mfd/tps65218.c
> @@ -235,9 +235,9 @@ static int tps65218_probe(struct i2c_client *client,
>  
>   mutex_init(>tps_lock);
>  
> - ret = regmap_add_irq_chip(tps->regmap, tps->irq,
> - IRQF_ONESHOT, 0, _irq_chip,
> - >irq_data);
> + ret = devm_regmap_add_irq_chip(>dev, tps->regmap, tps->irq,
> +IRQF_ONESHOT, 0, _irq_chip,
> +>irq_data);
>   if (ret < 0)
>   return ret;
>  
> @@ -253,23 +253,11 @@ static int tps65218_probe(struct i2c_client *client,
> ARRAY_SIZE(tps65218_cells), NULL, 0,
> regmap_irq_get_domain(tps->irq_data));
>  
> - if (ret < 0)
> - goto err_irq;
> -
> - return 0;
> -
> -err_irq:
> - regmap_del_irq_chip(tps->irq, tps->irq_data);
> -
>   return ret;
>  }
>  
>  static int tps65218_remove(struct i2c_client *client)
>  {
> - struct tps65218 *tps = i2c_get_clientdata(client);
> -
> - regmap_del_irq_chip(tps->irq, tps->irq_data);
> -
>   return 0;
>  }
>  
> -- 
> 1.9.1

Re: [PATCH] thermal: uniphier: Convert to SPDX identifier

[Daniel Lezcano]

On 07/12/2018 02:06, Kunihiko Hayashi wrote:
> This converts license boilerplate to SPDX identifier, and removes
> unnecessary lines.
> 
> Signed-off-by: Kunihiko Hayashi 
> ---

Reviewed-by: Daniel Lezcano 

>  drivers/thermal/uniphier_thermal.c | 13 +
>  1 file changed, 1 insertion(+), 12 deletions(-)
> 
> diff --git a/drivers/thermal/uniphier_thermal.c 
> b/drivers/thermal/uniphier_thermal.c
> index 55477d7..bba2284 100644
> --- a/drivers/thermal/uniphier_thermal.c
> +++ b/drivers/thermal/uniphier_thermal.c
> @@ -1,21 +1,10 @@
> +// SPDX-License-Identifier: GPL-2.0
>  /**
>   * uniphier_thermal.c - Socionext UniPhier thermal driver
> - *
>   * Copyright 2014  Panasonic Corporation
>   * Copyright 2016-2017 Socionext Inc.
> - * All rights reserved.
> - *
>   * Author:
>   *   Kunihiko Hayashi 
> - *
> - * This program is free software: you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2  of
> - * the License as published by the Free Software Foundation.
> - *
> - * 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.
>   */
>  
>  #include 
> 


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH] thermal: uniphier: Convert to SPDX identifier

[Daniel Lezcano]

On 07/12/2018 02:06, Kunihiko Hayashi wrote:
> This converts license boilerplate to SPDX identifier, and removes
> unnecessary lines.
> 
> Signed-off-by: Kunihiko Hayashi 
> ---

Reviewed-by: Daniel Lezcano 

>  drivers/thermal/uniphier_thermal.c | 13 +
>  1 file changed, 1 insertion(+), 12 deletions(-)
> 
> diff --git a/drivers/thermal/uniphier_thermal.c 
> b/drivers/thermal/uniphier_thermal.c
> index 55477d7..bba2284 100644
> --- a/drivers/thermal/uniphier_thermal.c
> +++ b/drivers/thermal/uniphier_thermal.c
> @@ -1,21 +1,10 @@
> +// SPDX-License-Identifier: GPL-2.0
>  /**
>   * uniphier_thermal.c - Socionext UniPhier thermal driver
> - *
>   * Copyright 2014  Panasonic Corporation
>   * Copyright 2016-2017 Socionext Inc.
> - * All rights reserved.
> - *
>   * Author:
>   *   Kunihiko Hayashi 
> - *
> - * This program is free software: you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2  of
> - * the License as published by the Free Software Foundation.
> - *
> - * 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.
>   */
>  
>  #include 
> 


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH v2 1/3] binder: fix sparse warnings on locking context

[Greg Kroah-Hartman]

On Thu, Dec 06, 2018 at 08:37:41AM -0800, Todd Kjos wrote:
> On Thu, Dec 6, 2018 at 6:51 AM Greg KH  wrote:
> >
> > On Wed, Dec 05, 2018 at 03:19:24PM -0800, Todd Kjos wrote:
> > > Add __acquire()/__release() annnotations to fix warnings
> > > in sparse context checking
> > >
> > > There is one case where the warning was due to a lack of
> > > a "default:" case in a switch statement where a lock was
> > > being released in each of the cases, so the default
> > > case was added.
> > >
> > > Signed-off-by: Todd Kjos 
> > > ---
> > > v2: no change, just resubmitted as #1 of 3 patches instead of by itself
> >
> > I've already applied this one, right?
> 
> No, not yet. I confused you by failing to add the "v2" in the subject
> for the other two submitted with it that you applied this morning:
> 
> binder: filter out nodes when showing binder procs
> binder: fix kerneldoc header for struct binder_buffer
> 
> Sorry about the confusion. This one still needs to be applied.

But I thought I applied this back on November 26:

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/commit/?h=char-misc-testing=324fa64cf4189094bc4df744a9e7214a1b81d845

You should have gotten an email from my scripts at that time.

or is this somehow a different patch with the same commit log?
Or a v2 that changed from the one that I had applied?  Do I need to
revert this one and apply your new one?

confused,

greg k-h

Re: linux-next: manual merge of the jc_docs tree with the fscrypt tree

[Jonathan Corbet]

On Fri, 7 Dec 2018 11:53:40 +1100
Stephen Rothwell  wrote:

> Today's linux-next merge of the jc_docs tree got a conflict in:
> 
>   Documentation/filesystems/index.rst
> 
> between commit:
> 
>   1b71a6809f96 ("fs-verity: add a documentation file")
> 
> from the fscrypt tree and commit:
> 
>   7bbfd9ad8eb2 ("Documentation: convert path-lookup from markdown to 
> resturctured text")
> 
> from the jc_docs tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

That fix is as good as any, thanks.

jon

Re: [PATCH v2 1/3] binder: fix sparse warnings on locking context

[Greg Kroah-Hartman]

On Thu, Dec 06, 2018 at 08:37:41AM -0800, Todd Kjos wrote:
> On Thu, Dec 6, 2018 at 6:51 AM Greg KH  wrote:
> >
> > On Wed, Dec 05, 2018 at 03:19:24PM -0800, Todd Kjos wrote:
> > > Add __acquire()/__release() annnotations to fix warnings
> > > in sparse context checking
> > >
> > > There is one case where the warning was due to a lack of
> > > a "default:" case in a switch statement where a lock was
> > > being released in each of the cases, so the default
> > > case was added.
> > >
> > > Signed-off-by: Todd Kjos 
> > > ---
> > > v2: no change, just resubmitted as #1 of 3 patches instead of by itself
> >
> > I've already applied this one, right?
> 
> No, not yet. I confused you by failing to add the "v2" in the subject
> for the other two submitted with it that you applied this morning:
> 
> binder: filter out nodes when showing binder procs
> binder: fix kerneldoc header for struct binder_buffer
> 
> Sorry about the confusion. This one still needs to be applied.

But I thought I applied this back on November 26:

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/commit/?h=char-misc-testing=324fa64cf4189094bc4df744a9e7214a1b81d845

You should have gotten an email from my scripts at that time.

or is this somehow a different patch with the same commit log?
Or a v2 that changed from the one that I had applied?  Do I need to
revert this one and apply your new one?

confused,

greg k-h

Re: linux-next: manual merge of the jc_docs tree with the fscrypt tree

[Jonathan Corbet]

On Fri, 7 Dec 2018 11:53:40 +1100
Stephen Rothwell  wrote:

> Today's linux-next merge of the jc_docs tree got a conflict in:
> 
>   Documentation/filesystems/index.rst
> 
> between commit:
> 
>   1b71a6809f96 ("fs-verity: add a documentation file")
> 
> from the fscrypt tree and commit:
> 
>   7bbfd9ad8eb2 ("Documentation: convert path-lookup from markdown to 
> resturctured text")
> 
> from the jc_docs tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

That fix is as good as any, thanks.

jon

Re: [PATCH] clocksource/drivers/timer-imx-tpm: Specify clock name for timer-of

[Daniel Lezcano]

On 07/12/2018 07:05, Anson Huang wrote:
> i.MX TPM needs "ipg" clock for register access and "per" clock for
> timer function, the driver gets "ipg" clock by searching the clock
> name, but timer-of initialization will get first clock in device
> tree TPM node since no clock name specified in of_clk, that means
> the "per" clock MUST be the first clock entry in device tree TPM
> node, this patch specifies clock name for of_clk to avoid this
> restriction, it makes TPM driver work properly with different sequence
> of clock entries in device tree TPM node.
> 
> Signed-off-by: Anson Huang 
> ---

Applied.

Thanks.

  -- Daniel


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH] clocksource/drivers/timer-imx-tpm: Specify clock name for timer-of

[Daniel Lezcano]

On 07/12/2018 07:05, Anson Huang wrote:
> i.MX TPM needs "ipg" clock for register access and "per" clock for
> timer function, the driver gets "ipg" clock by searching the clock
> name, but timer-of initialization will get first clock in device
> tree TPM node since no clock name specified in of_clk, that means
> the "per" clock MUST be the first clock entry in device tree TPM
> node, this patch specifies clock name for of_clk to avoid this
> restriction, it makes TPM driver work properly with different sequence
> of clock entries in device tree TPM node.
> 
> Signed-off-by: Anson Huang 
> ---

Applied.

Thanks.

  -- Daniel


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH v2] clocksource/drivers/fttmr010: fix invalid interrupt register access

[Daniel Lezcano]

On 07/12/2018 02:13, Tao Ren wrote:
> On 11/5/18, 11:00 AM, "Tao Ren"  wrote:
> 
>> On 11/5/18, 10:51 AM, "Daniel Lezcano"  wrote:
>>> Oh right, sorry. Should it go to stable also ? Is there a Fixes tag it can 
>>> apply ?
>>>
>> Personally I don't think it needs to go to stable, because I don't see any 
>> functional failures caused by this invalid register access.
> 
> Hi Daniel,
> 
> Not sure if I missed any emails from you, but looks like the patch is not 
> included in your tree? Are we planning to include the patch in 4.21 merge 
> window?

Yes, I have it in the tree. I updated the next branch.

Thanks

  -- Daniel


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: > [PATCH] Security: Handle hidepid option correctly

[程洋]

@Nick. Would mind giving this patch an "Acked-by"?
This issue causes any Android who uses latest kernel cannot mount proc
with "hidepid=2" option. Which causes problems
程洋  于2018年12月5日周三 下午3:26写道：
>
> Anyone who can review my patch?
>
> 程洋  于2018年11月30日周五 上午10:34写道：
> >
> > Here is an article illustrates the details.
> > https://medium.com/@topjohnwu/from-anime-game-to-android-system-security-vulnerability-9b955a182f20
> >
> > And There is a similar fix on kernel-4.4:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=99663be772c827b8f5f594fe87eb4807be1994e5
> >
> > Q: Other filesystems parse the options from fill_super().  Is proc special 
> > in some fashion?
> > A: According to my research, start_kernel will call proc_mount first, and 
> > initialize sb->s_root before any userspace process runs. If others want to 
> > mount it, all options will be ignored.
> >  AOSP change here: 
> > https://android-review.googlesource.com/c/platform/system/core/+/181345/4/init/init.cpp
> >  At first I though we should mount it with MS_REMOUNT flag. But kernel 
> > will crash if we did this.
> >
> > Q:  Why is this considered to be security sensitive?  I can guess, but I'd 
> > like to know your reasoning.
> > A: See the article above. It's part of Android sanbox.
> >
> >
> > > [PATCH] Security: Handle hidepid option correctly
> >
> > Why is this considered to be security sensitive?  I can guess, but I'd like 
> > to know your reasoning.
> >
> > On Thu, 29 Nov 2018 19:08:21 +0800 mailto:d17103...@gmail.com wrote:
> >
> > > From: Cheng Yang 
> > >
> > > The proc_parse_options() call from proc_mount() runs only once at boot
> > > time.  So on any later mount attempt, any mount options are ignored
> > > because ->s_root is already initialized.
> > > As a consequence, "mount -o " will ignore the options.  The
> > > only way to change mount options is "mount -o remount,".
> > > To fix this, parse the mount options unconditionally.
> > >
> > > --- a/fs/proc/inode.c
> > > +++ b/fs/proc/inode.c
> > > @@ -493,13 +493,9 @@ struct inode *proc_get_inode(struct super_block
> > > *sb, struct proc_dir_entry *de)
> > >
> > >  int proc_fill_super(struct super_block *s, void *data, int silent)  {
> > > -struct pid_namespace *ns = get_pid_ns(s->s_fs_info);
> > >  struct inode *root_inode;
> > >  int ret;
> > >
> > > -if (!proc_parse_options(data, ns))
> > > -return -EINVAL;
> > > -
> > >  /* User space would break if executables or devices appear on proc */
> > >  s->s_iflags |= SB_I_USERNS_VISIBLE | SB_I_NOEXEC | SB_I_NODEV;
> > >  s->s_flags |= SB_NODIRATIME | SB_NOSUID | SB_NOEXEC; diff --git
> > > a/fs/proc/root.c b/fs/proc/root.c index f4b1a9d..f5f3bf3 100644
> > > --- a/fs/proc/root.c
> > > +++ b/fs/proc/root.c
> > > @@ -98,6 +98,9 @@ static struct dentry *proc_mount(struct 
> > > file_system_type *fs_type,
> > >  ns = task_active_pid_ns(current);
> > >  }
> > >
> > > +if (!proc_parse_options(data, ns))
> > > +return ERR_PTR(-EINVAL);
> > > +
> > >  return mount_ns(fs_type, flags, data, ns, ns->user_ns,
> > > proc_fill_super);  }
> >
> > Other filesystems parse the options from fill_super().  Is proc special in 
> > some fashion?
> >
> > #/**本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> >  This e-mail and its attachments contain confidential information from 
> > XIAOMI, which is intended only for the person or entity whose address is 
> > listed above. Any use of the information contained herein in any way 
> > (including, but not limited to, total or partial disclosure, reproduction, 
> > or dissemination) by persons other than the intended recipient(s) is 
> > prohibited. If you receive this e-mail in error, please notify the sender 
> > by phone or email immediately and delete it!**/#

Re: [PATCH v2] clocksource/drivers/fttmr010: fix invalid interrupt register access

[Daniel Lezcano]

On 07/12/2018 02:13, Tao Ren wrote:
> On 11/5/18, 11:00 AM, "Tao Ren"  wrote:
> 
>> On 11/5/18, 10:51 AM, "Daniel Lezcano"  wrote:
>>> Oh right, sorry. Should it go to stable also ? Is there a Fixes tag it can 
>>> apply ?
>>>
>> Personally I don't think it needs to go to stable, because I don't see any 
>> functional failures caused by this invalid register access.
> 
> Hi Daniel,
> 
> Not sure if I missed any emails from you, but looks like the patch is not 
> included in your tree? Are we planning to include the patch in 4.21 merge 
> window?

Yes, I have it in the tree. I updated the next branch.

Thanks

  -- Daniel


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: > [PATCH] Security: Handle hidepid option correctly

[程洋]

@Nick. Would mind giving this patch an "Acked-by"?
This issue causes any Android who uses latest kernel cannot mount proc
with "hidepid=2" option. Which causes problems
程洋  于2018年12月5日周三 下午3:26写道：
>
> Anyone who can review my patch?
>
> 程洋  于2018年11月30日周五 上午10:34写道：
> >
> > Here is an article illustrates the details.
> > https://medium.com/@topjohnwu/from-anime-game-to-android-system-security-vulnerability-9b955a182f20
> >
> > And There is a similar fix on kernel-4.4:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=99663be772c827b8f5f594fe87eb4807be1994e5
> >
> > Q: Other filesystems parse the options from fill_super().  Is proc special 
> > in some fashion?
> > A: According to my research, start_kernel will call proc_mount first, and 
> > initialize sb->s_root before any userspace process runs. If others want to 
> > mount it, all options will be ignored.
> >  AOSP change here: 
> > https://android-review.googlesource.com/c/platform/system/core/+/181345/4/init/init.cpp
> >  At first I though we should mount it with MS_REMOUNT flag. But kernel 
> > will crash if we did this.
> >
> > Q:  Why is this considered to be security sensitive?  I can guess, but I'd 
> > like to know your reasoning.
> > A: See the article above. It's part of Android sanbox.
> >
> >
> > > [PATCH] Security: Handle hidepid option correctly
> >
> > Why is this considered to be security sensitive?  I can guess, but I'd like 
> > to know your reasoning.
> >
> > On Thu, 29 Nov 2018 19:08:21 +0800 mailto:d17103...@gmail.com wrote:
> >
> > > From: Cheng Yang 
> > >
> > > The proc_parse_options() call from proc_mount() runs only once at boot
> > > time.  So on any later mount attempt, any mount options are ignored
> > > because ->s_root is already initialized.
> > > As a consequence, "mount -o " will ignore the options.  The
> > > only way to change mount options is "mount -o remount,".
> > > To fix this, parse the mount options unconditionally.
> > >
> > > --- a/fs/proc/inode.c
> > > +++ b/fs/proc/inode.c
> > > @@ -493,13 +493,9 @@ struct inode *proc_get_inode(struct super_block
> > > *sb, struct proc_dir_entry *de)
> > >
> > >  int proc_fill_super(struct super_block *s, void *data, int silent)  {
> > > -struct pid_namespace *ns = get_pid_ns(s->s_fs_info);
> > >  struct inode *root_inode;
> > >  int ret;
> > >
> > > -if (!proc_parse_options(data, ns))
> > > -return -EINVAL;
> > > -
> > >  /* User space would break if executables or devices appear on proc */
> > >  s->s_iflags |= SB_I_USERNS_VISIBLE | SB_I_NOEXEC | SB_I_NODEV;
> > >  s->s_flags |= SB_NODIRATIME | SB_NOSUID | SB_NOEXEC; diff --git
> > > a/fs/proc/root.c b/fs/proc/root.c index f4b1a9d..f5f3bf3 100644
> > > --- a/fs/proc/root.c
> > > +++ b/fs/proc/root.c
> > > @@ -98,6 +98,9 @@ static struct dentry *proc_mount(struct 
> > > file_system_type *fs_type,
> > >  ns = task_active_pid_ns(current);
> > >  }
> > >
> > > +if (!proc_parse_options(data, ns))
> > > +return ERR_PTR(-EINVAL);
> > > +
> > >  return mount_ns(fs_type, flags, data, ns, ns->user_ns,
> > > proc_fill_super);  }
> >
> > Other filesystems parse the options from fill_super().  Is proc special in 
> > some fashion?
> >
> > #/**本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> >  This e-mail and its attachments contain confidential information from 
> > XIAOMI, which is intended only for the person or entity whose address is 
> > listed above. Any use of the information contained herein in any way 
> > (including, but not limited to, total or partial disclosure, reproduction, 
> > or dissemination) by persons other than the intended recipient(s) is 
> > prohibited. If you receive this e-mail in error, please notify the sender 
> > by phone or email immediately and delete it!**/#

Re: linux-next: build failure after merge of the thermal tree

[Amit Kucheria]

Hi Stephen, Rui,

On Fri, Dec 7, 2018 at 6:55 AM Stephen Rothwell  wrote:
>
> Hi Zhang,
>
> After merging the thermal tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/thermal/qcom/qcom-spmi-temp-alarm.c:26:10: fatal error: 
> thermal_core.h: No such file or directory
>  #include "thermal_core.h"
>   ^~~~
>
> Caused by commit
>
>   150a4fe8c335 ("drivers: thermal: Move QCOM_SPMI_TEMP_ALARM into the qcom 
> subdir")

Apologies for the build error. My scripts failed to enable the config
and test it correctly. There was bug on where the .config file ended
up. I've fixed it and sent v4 of the patches. Please consider applying
them instead.

Regards,
Amit

> I have used the thermal tree from next-20181206 for today.
>
> --
> Cheers,
> Stephen Rothwell

Re: linux-next: build failure after merge of the thermal tree

[Amit Kucheria]

Hi Stephen, Rui,

On Fri, Dec 7, 2018 at 6:55 AM Stephen Rothwell  wrote:
>
> Hi Zhang,
>
> After merging the thermal tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/thermal/qcom/qcom-spmi-temp-alarm.c:26:10: fatal error: 
> thermal_core.h: No such file or directory
>  #include "thermal_core.h"
>   ^~~~
>
> Caused by commit
>
>   150a4fe8c335 ("drivers: thermal: Move QCOM_SPMI_TEMP_ALARM into the qcom 
> subdir")

Apologies for the build error. My scripts failed to enable the config
and test it correctly. There was bug on where the .config file ended
up. I've fixed it and sent v4 of the patches. Please consider applying
them instead.

Regards,
Amit

> I have used the thermal tree from next-20181206 for today.
>
> --
> Cheers,
> Stephen Rothwell

[PATCH v4 0/2] driver: thermal: Move some drivers into subdirs

[Amit Kucheria]

(Apologies for the build failure. My scripts to enable these configs and
build-test them failed. They've been fixed now)

Move the various drivers for Intel platforms into their own subdir. Also
consolidate Qualcomm drivers into the qcom subdir.

This cleans up the directory making it easier to find things.

There is no great time to send patches that move files around. So here's an
attempt to sneak it into 4.21 before everything else.

This was generated and compile-tested against 4.20-rc4. If you would like
me to try again a bit later, I'm happy to do so.

Changes since v3:
- Fix build failure on QCOM_SPMI_TEMP_ALARM

Changes since v2:
- Rebased on top of 4.20-rc4

Changes since v1:
- Removed a stray character that snuck into the Makefile
- Added Acks
- Rebased to v4.19-rc6


Amit Kucheria (2):
  drivers: thermal: Move various drivers for intel platforms into a
subdir
  drivers: thermal: Move QCOM_SPMI_TEMP_ALARM into the qcom subdir

 drivers/thermal/Kconfig   | 94 +--
 drivers/thermal/Makefile  | 10 +-
 drivers/thermal/intel/Kconfig | 77 +++
 drivers/thermal/intel/Makefile| 12 +++
 .../{ => intel}/int340x_thermal/Kconfig   |  0
 .../{ => intel}/int340x_thermal/Makefile  |  0
 .../int340x_thermal/acpi_thermal_rel.c|  0
 .../int340x_thermal/acpi_thermal_rel.h|  0
 .../int340x_thermal/int3400_thermal.c |  0
 .../int340x_thermal/int3402_thermal.c |  0
 .../int340x_thermal/int3403_thermal.c |  0
 .../int340x_thermal/int3406_thermal.c |  0
 .../int340x_thermal/int340x_thermal_zone.c|  0
 .../int340x_thermal/int340x_thermal_zone.h|  0
 .../processor_thermal_device.c|  0
 .../{ => intel}/intel_bxt_pmic_thermal.c  |  0
 .../thermal/{ => intel}/intel_pch_thermal.c   |  0
 .../thermal/{ => intel}/intel_powerclamp.c|  0
 .../{ => intel}/intel_quark_dts_thermal.c |  0
 .../thermal/{ => intel}/intel_soc_dts_iosf.c  |  0
 .../thermal/{ => intel}/intel_soc_dts_iosf.h  |  0
 .../{ => intel}/intel_soc_dts_thermal.c   |  0
 .../{ => intel}/x86_pkg_temp_thermal.c|  0
 drivers/thermal/qcom/Kconfig  | 11 +++
 drivers/thermal/qcom/Makefile |  1 +
 .../thermal/{ => qcom}/qcom-spmi-temp-alarm.c |  2 +-
 26 files changed, 108 insertions(+), 99 deletions(-)
 create mode 100644 drivers/thermal/intel/Kconfig
 create mode 100644 drivers/thermal/intel/Makefile
 rename drivers/thermal/{ => intel}/int340x_thermal/Kconfig (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/Makefile (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/acpi_thermal_rel.c (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/acpi_thermal_rel.h (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/int3400_thermal.c (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/int3402_thermal.c (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/int3403_thermal.c (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/int3406_thermal.c (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/int340x_thermal_zone.c 
(100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/int340x_thermal_zone.h 
(100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/processor_thermal_device.c 
(100%)
 rename drivers/thermal/{ => intel}/intel_bxt_pmic_thermal.c (100%)
 rename drivers/thermal/{ => intel}/intel_pch_thermal.c (100%)
 rename drivers/thermal/{ => intel}/intel_powerclamp.c (100%)
 rename drivers/thermal/{ => intel}/intel_quark_dts_thermal.c (100%)
 rename drivers/thermal/{ => intel}/intel_soc_dts_iosf.c (100%)
 rename drivers/thermal/{ => intel}/intel_soc_dts_iosf.h (100%)
 rename drivers/thermal/{ => intel}/intel_soc_dts_thermal.c (100%)
 rename drivers/thermal/{ => intel}/x86_pkg_temp_thermal.c (100%)
 rename drivers/thermal/{ => qcom}/qcom-spmi-temp-alarm.c (99%)

-- 
2.17.1

[PATCH v4 1/2] drivers: thermal: Move various drivers for intel platforms into a subdir

[Amit Kucheria]

This cleans up the directory a bit, now that we have several other
platforms using platform-specific sub-directories. Compile-tested with
ARCH=x86 defconfig and the drivers explicitly enabled with menuconfig.

Signed-off-by: Amit Kucheria 
Acked-by: Daniel Lezcano 
---
 drivers/thermal/Kconfig   | 83 ++-
 drivers/thermal/Makefile  |  9 +-
 drivers/thermal/intel/Kconfig | 77 +
 drivers/thermal/intel/Makefile| 12 +++
 .../{ => intel}/int340x_thermal/Kconfig   |  0
 .../{ => intel}/int340x_thermal/Makefile  |  0
 .../int340x_thermal/acpi_thermal_rel.c|  0
 .../int340x_thermal/acpi_thermal_rel.h|  0
 .../int340x_thermal/int3400_thermal.c |  0
 .../int340x_thermal/int3402_thermal.c |  0
 .../int340x_thermal/int3403_thermal.c |  0
 .../int340x_thermal/int3406_thermal.c |  0
 .../int340x_thermal/int340x_thermal_zone.c|  0
 .../int340x_thermal/int340x_thermal_zone.h|  0
 .../processor_thermal_device.c|  0
 .../{ => intel}/intel_bxt_pmic_thermal.c  |  0
 .../thermal/{ => intel}/intel_pch_thermal.c   |  0
 .../thermal/{ => intel}/intel_powerclamp.c|  0
 .../{ => intel}/intel_quark_dts_thermal.c |  0
 .../thermal/{ => intel}/intel_soc_dts_iosf.c  |  0
 .../thermal/{ => intel}/intel_soc_dts_iosf.h  |  0
 .../{ => intel}/intel_soc_dts_thermal.c   |  0
 .../{ => intel}/x86_pkg_temp_thermal.c|  0
 23 files changed, 95 insertions(+), 86 deletions(-)
 create mode 100644 drivers/thermal/intel/Kconfig
 create mode 100644 drivers/thermal/intel/Makefile
 rename drivers/thermal/{ => intel}/int340x_thermal/Kconfig (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/Makefile (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/acpi_thermal_rel.c (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/acpi_thermal_rel.h (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/int3400_thermal.c (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/int3402_thermal.c (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/int3403_thermal.c (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/int3406_thermal.c (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/int340x_thermal_zone.c 
(100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/int340x_thermal_zone.h 
(100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/processor_thermal_device.c 
(100%)
 rename drivers/thermal/{ => intel}/intel_bxt_pmic_thermal.c (100%)
 rename drivers/thermal/{ => intel}/intel_pch_thermal.c (100%)
 rename drivers/thermal/{ => intel}/intel_powerclamp.c (100%)
 rename drivers/thermal/{ => intel}/intel_quark_dts_thermal.c (100%)
 rename drivers/thermal/{ => intel}/intel_soc_dts_iosf.c (100%)
 rename drivers/thermal/{ => intel}/intel_soc_dts_iosf.h (100%)
 rename drivers/thermal/{ => intel}/intel_soc_dts_thermal.c (100%)
 rename drivers/thermal/{ => intel}/x86_pkg_temp_thermal.c (100%)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 5422523c03f8..772ab9dadda7 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -326,84 +326,6 @@ config DA9062_THERMAL
  zone.
  Compatible with the DA9062 and DA9061 PMICs.
 
-config INTEL_POWERCLAMP
-   tristate "Intel PowerClamp idle injection driver"
-   depends on THERMAL
-   depends on X86
-   depends on CPU_SUP_INTEL
-   help
- Enable this to enable Intel PowerClamp idle injection driver. This
- enforce idle time which results in more package C-state residency. The
- user interface is exposed via generic thermal framework.
-
-config X86_PKG_TEMP_THERMAL
-   tristate "X86 package temperature thermal driver"
-   depends on X86_THERMAL_VECTOR
-   select THERMAL_GOV_USER_SPACE
-   select THERMAL_WRITABLE_TRIPS
-   default m
-   help
- Enable this to register CPU digital sensor for package temperature as
- thermal zone. Each package will have its own thermal zone. There are
- two trip points which can be set by user to get notifications via 
thermal
- notification methods.
-
-config INTEL_SOC_DTS_IOSF_CORE
-   tristate
-   depends on X86 && PCI
-   select IOSF_MBI
-   help
- This is becoming a common feature for Intel SoCs to expose the 
additional
- digital temperature sensors (DTSs) using side band interface (IOSF). 
This
- implements the common set of helper functions to register, get 
temperature
- and get/set thresholds on DTSs.
-
-config INTEL_SOC_DTS_THERMAL
-   tristate "Intel SoCs DTS thermal driver"
-   depends on X86 && PCI && ACPI
-   select INTEL_SOC_DTS_IOSF_CORE
-   select THERMAL_WRITABLE_TRIPS
-   help
- Enable this to register Intel SoCs (e.g. Bay Trail) platform digital
- temperature sensor (DTS). These SoCs have two 

[PATCH v4 0/2] driver: thermal: Move some drivers into subdirs

[Amit Kucheria]

(Apologies for the build failure. My scripts to enable these configs and
build-test them failed. They've been fixed now)

Move the various drivers for Intel platforms into their own subdir. Also
consolidate Qualcomm drivers into the qcom subdir.

This cleans up the directory making it easier to find things.

There is no great time to send patches that move files around. So here's an
attempt to sneak it into 4.21 before everything else.

This was generated and compile-tested against 4.20-rc4. If you would like
me to try again a bit later, I'm happy to do so.

Changes since v3:
- Fix build failure on QCOM_SPMI_TEMP_ALARM

Changes since v2:
- Rebased on top of 4.20-rc4

Changes since v1:
- Removed a stray character that snuck into the Makefile
- Added Acks
- Rebased to v4.19-rc6


Amit Kucheria (2):
  drivers: thermal: Move various drivers for intel platforms into a
subdir
  drivers: thermal: Move QCOM_SPMI_TEMP_ALARM into the qcom subdir

 drivers/thermal/Kconfig   | 94 +--
 drivers/thermal/Makefile  | 10 +-
 drivers/thermal/intel/Kconfig | 77 +++
 drivers/thermal/intel/Makefile| 12 +++
 .../{ => intel}/int340x_thermal/Kconfig   |  0
 .../{ => intel}/int340x_thermal/Makefile  |  0
 .../int340x_thermal/acpi_thermal_rel.c|  0
 .../int340x_thermal/acpi_thermal_rel.h|  0
 .../int340x_thermal/int3400_thermal.c |  0
 .../int340x_thermal/int3402_thermal.c |  0
 .../int340x_thermal/int3403_thermal.c |  0
 .../int340x_thermal/int3406_thermal.c |  0
 .../int340x_thermal/int340x_thermal_zone.c|  0
 .../int340x_thermal/int340x_thermal_zone.h|  0
 .../processor_thermal_device.c|  0
 .../{ => intel}/intel_bxt_pmic_thermal.c  |  0
 .../thermal/{ => intel}/intel_pch_thermal.c   |  0
 .../thermal/{ => intel}/intel_powerclamp.c|  0
 .../{ => intel}/intel_quark_dts_thermal.c |  0
 .../thermal/{ => intel}/intel_soc_dts_iosf.c  |  0
 .../thermal/{ => intel}/intel_soc_dts_iosf.h  |  0
 .../{ => intel}/intel_soc_dts_thermal.c   |  0
 .../{ => intel}/x86_pkg_temp_thermal.c|  0
 drivers/thermal/qcom/Kconfig  | 11 +++
 drivers/thermal/qcom/Makefile |  1 +
 .../thermal/{ => qcom}/qcom-spmi-temp-alarm.c |  2 +-
 26 files changed, 108 insertions(+), 99 deletions(-)
 create mode 100644 drivers/thermal/intel/Kconfig
 create mode 100644 drivers/thermal/intel/Makefile
 rename drivers/thermal/{ => intel}/int340x_thermal/Kconfig (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/Makefile (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/acpi_thermal_rel.c (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/acpi_thermal_rel.h (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/int3400_thermal.c (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/int3402_thermal.c (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/int3403_thermal.c (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/int3406_thermal.c (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/int340x_thermal_zone.c 
(100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/int340x_thermal_zone.h 
(100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/processor_thermal_device.c 
(100%)
 rename drivers/thermal/{ => intel}/intel_bxt_pmic_thermal.c (100%)
 rename drivers/thermal/{ => intel}/intel_pch_thermal.c (100%)
 rename drivers/thermal/{ => intel}/intel_powerclamp.c (100%)
 rename drivers/thermal/{ => intel}/intel_quark_dts_thermal.c (100%)
 rename drivers/thermal/{ => intel}/intel_soc_dts_iosf.c (100%)
 rename drivers/thermal/{ => intel}/intel_soc_dts_iosf.h (100%)
 rename drivers/thermal/{ => intel}/intel_soc_dts_thermal.c (100%)
 rename drivers/thermal/{ => intel}/x86_pkg_temp_thermal.c (100%)
 rename drivers/thermal/{ => qcom}/qcom-spmi-temp-alarm.c (99%)

-- 
2.17.1

[PATCH v4 1/2] drivers: thermal: Move various drivers for intel platforms into a subdir

[Amit Kucheria]

This cleans up the directory a bit, now that we have several other
platforms using platform-specific sub-directories. Compile-tested with
ARCH=x86 defconfig and the drivers explicitly enabled with menuconfig.

Signed-off-by: Amit Kucheria 
Acked-by: Daniel Lezcano 
---
 drivers/thermal/Kconfig   | 83 ++-
 drivers/thermal/Makefile  |  9 +-
 drivers/thermal/intel/Kconfig | 77 +
 drivers/thermal/intel/Makefile| 12 +++
 .../{ => intel}/int340x_thermal/Kconfig   |  0
 .../{ => intel}/int340x_thermal/Makefile  |  0
 .../int340x_thermal/acpi_thermal_rel.c|  0
 .../int340x_thermal/acpi_thermal_rel.h|  0
 .../int340x_thermal/int3400_thermal.c |  0
 .../int340x_thermal/int3402_thermal.c |  0
 .../int340x_thermal/int3403_thermal.c |  0
 .../int340x_thermal/int3406_thermal.c |  0
 .../int340x_thermal/int340x_thermal_zone.c|  0
 .../int340x_thermal/int340x_thermal_zone.h|  0
 .../processor_thermal_device.c|  0
 .../{ => intel}/intel_bxt_pmic_thermal.c  |  0
 .../thermal/{ => intel}/intel_pch_thermal.c   |  0
 .../thermal/{ => intel}/intel_powerclamp.c|  0
 .../{ => intel}/intel_quark_dts_thermal.c |  0
 .../thermal/{ => intel}/intel_soc_dts_iosf.c  |  0
 .../thermal/{ => intel}/intel_soc_dts_iosf.h  |  0
 .../{ => intel}/intel_soc_dts_thermal.c   |  0
 .../{ => intel}/x86_pkg_temp_thermal.c|  0
 23 files changed, 95 insertions(+), 86 deletions(-)
 create mode 100644 drivers/thermal/intel/Kconfig
 create mode 100644 drivers/thermal/intel/Makefile
 rename drivers/thermal/{ => intel}/int340x_thermal/Kconfig (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/Makefile (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/acpi_thermal_rel.c (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/acpi_thermal_rel.h (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/int3400_thermal.c (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/int3402_thermal.c (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/int3403_thermal.c (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/int3406_thermal.c (100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/int340x_thermal_zone.c 
(100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/int340x_thermal_zone.h 
(100%)
 rename drivers/thermal/{ => intel}/int340x_thermal/processor_thermal_device.c 
(100%)
 rename drivers/thermal/{ => intel}/intel_bxt_pmic_thermal.c (100%)
 rename drivers/thermal/{ => intel}/intel_pch_thermal.c (100%)
 rename drivers/thermal/{ => intel}/intel_powerclamp.c (100%)
 rename drivers/thermal/{ => intel}/intel_quark_dts_thermal.c (100%)
 rename drivers/thermal/{ => intel}/intel_soc_dts_iosf.c (100%)
 rename drivers/thermal/{ => intel}/intel_soc_dts_iosf.h (100%)
 rename drivers/thermal/{ => intel}/intel_soc_dts_thermal.c (100%)
 rename drivers/thermal/{ => intel}/x86_pkg_temp_thermal.c (100%)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 5422523c03f8..772ab9dadda7 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -326,84 +326,6 @@ config DA9062_THERMAL
  zone.
  Compatible with the DA9062 and DA9061 PMICs.
 
-config INTEL_POWERCLAMP
-   tristate "Intel PowerClamp idle injection driver"
-   depends on THERMAL
-   depends on X86
-   depends on CPU_SUP_INTEL
-   help
- Enable this to enable Intel PowerClamp idle injection driver. This
- enforce idle time which results in more package C-state residency. The
- user interface is exposed via generic thermal framework.
-
-config X86_PKG_TEMP_THERMAL
-   tristate "X86 package temperature thermal driver"
-   depends on X86_THERMAL_VECTOR
-   select THERMAL_GOV_USER_SPACE
-   select THERMAL_WRITABLE_TRIPS
-   default m
-   help
- Enable this to register CPU digital sensor for package temperature as
- thermal zone. Each package will have its own thermal zone. There are
- two trip points which can be set by user to get notifications via 
thermal
- notification methods.
-
-config INTEL_SOC_DTS_IOSF_CORE
-   tristate
-   depends on X86 && PCI
-   select IOSF_MBI
-   help
- This is becoming a common feature for Intel SoCs to expose the 
additional
- digital temperature sensors (DTSs) using side band interface (IOSF). 
This
- implements the common set of helper functions to register, get 
temperature
- and get/set thresholds on DTSs.
-
-config INTEL_SOC_DTS_THERMAL
-   tristate "Intel SoCs DTS thermal driver"
-   depends on X86 && PCI && ACPI
-   select INTEL_SOC_DTS_IOSF_CORE
-   select THERMAL_WRITABLE_TRIPS
-   help
- Enable this to register Intel SoCs (e.g. Bay Trail) platform digital
- temperature sensor (DTS). These SoCs have two 

[PATCH v4 2/2] drivers: thermal: Move QCOM_SPMI_TEMP_ALARM into the qcom subdir

[Amit Kucheria]

This cleans up the directory a bit allowing just one place to look for
thermal related drivers for QCOM platforms instead of being scattered in
the root directory and the qcom/ subdirectory. Compile-tested with
ARCH=arm64 defconfig and the driver explicitly enabled with menuconfig.

Signed-off-by: Amit Kucheria 
Acked-by: Daniel Lezcano 
---
 drivers/thermal/Kconfig   | 11 ---
 drivers/thermal/Makefile  |  1 -
 drivers/thermal/qcom/Kconfig  | 11 +++
 drivers/thermal/qcom/Makefile |  1 +
 drivers/thermal/{ => qcom}/qcom-spmi-temp-alarm.c |  2 +-
 5 files changed, 13 insertions(+), 13 deletions(-)
 rename drivers/thermal/{ => qcom}/qcom-spmi-temp-alarm.c (99%)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 772ab9dadda7..344f6459862b 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -374,17 +374,6 @@ config TANGO_THERMAL
 
 source "drivers/thermal/tegra/Kconfig"
 
-config QCOM_SPMI_TEMP_ALARM
-   tristate "Qualcomm SPMI PMIC Temperature Alarm"
-   depends on OF && SPMI && IIO
-   select REGMAP_SPMI
-   help
- This enables a thermal sysfs driver for Qualcomm plug-and-play (QPNP)
- PMIC devices. It shows up in sysfs as a thermal sensor with multiple
- trip points. The temperature reported by the thermal sensor reflects 
the
- real time die temperature if an ADC is present or an estimate of the
- temperature based upon the over temperature stage value.
-
 config GENERIC_ADC_THERMAL
tristate "Generic ADC based thermal sensor"
depends on IIO
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 0b5d33a49b3e..486d682be047 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -29,7 +29,6 @@ thermal_sys-$(CONFIG_DEVFREQ_THERMAL) += devfreq_cooling.o
 
 # platform thermal drivers
 obj-y  += broadcom/
-obj-$(CONFIG_QCOM_SPMI_TEMP_ALARM) += qcom-spmi-temp-alarm.o
 obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
 obj-$(CONFIG_ROCKCHIP_THERMAL) += rockchip_thermal.o
 obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
diff --git a/drivers/thermal/qcom/Kconfig b/drivers/thermal/qcom/Kconfig
index be32e5abce3c..cdb455ffd575 100644
--- a/drivers/thermal/qcom/Kconfig
+++ b/drivers/thermal/qcom/Kconfig
@@ -9,3 +9,14 @@ config QCOM_TSENS
  thermal zone device via the mode file results in disabling the sensor.
  Also able to set threshold temperature for both hot and cold and 
update
  when a threshold is reached.
+
+config QCOM_SPMI_TEMP_ALARM
+   tristate "Qualcomm SPMI PMIC Temperature Alarm"
+   depends on OF && SPMI && IIO
+   select REGMAP_SPMI
+   help
+ This enables a thermal sysfs driver for Qualcomm plug-and-play (QPNP)
+ PMIC devices. It shows up in sysfs as a thermal sensor with multiple
+ trip points. The temperature reported by the thermal sensor reflects 
the
+ real time die temperature if an ADC is present or an estimate of the
+ temperature based upon the over temperature stage value.
diff --git a/drivers/thermal/qcom/Makefile b/drivers/thermal/qcom/Makefile
index a821929ede0b..717a08600bb5 100644
--- a/drivers/thermal/qcom/Makefile
+++ b/drivers/thermal/qcom/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_QCOM_TSENS)   += qcom_tsens.o
 qcom_tsens-y   += tsens.o tsens-common.o tsens-8916.o 
tsens-8974.o tsens-8960.o tsens-v2.o
+obj-$(CONFIG_QCOM_SPMI_TEMP_ALARM) += qcom-spmi-temp-alarm.o
diff --git a/drivers/thermal/qcom-spmi-temp-alarm.c 
b/drivers/thermal/qcom/qcom-spmi-temp-alarm.c
similarity index 99%
rename from drivers/thermal/qcom-spmi-temp-alarm.c
rename to drivers/thermal/qcom/qcom-spmi-temp-alarm.c
index b2d5d5bf4a9b..c1fd71dbab3e 100644
--- a/drivers/thermal/qcom-spmi-temp-alarm.c
+++ b/drivers/thermal/qcom/qcom-spmi-temp-alarm.c
@@ -23,7 +23,7 @@
 #include 
 #include 
 
-#include "thermal_core.h"
+#include "../thermal_core.h"
 
 #define QPNP_TM_REG_TYPE   0x04
 #define QPNP_TM_REG_SUBTYPE0x05
-- 
2.17.1

[PATCH v4 2/2] drivers: thermal: Move QCOM_SPMI_TEMP_ALARM into the qcom subdir

[Amit Kucheria]

This cleans up the directory a bit allowing just one place to look for
thermal related drivers for QCOM platforms instead of being scattered in
the root directory and the qcom/ subdirectory. Compile-tested with
ARCH=arm64 defconfig and the driver explicitly enabled with menuconfig.

Signed-off-by: Amit Kucheria 
Acked-by: Daniel Lezcano 
---
 drivers/thermal/Kconfig   | 11 ---
 drivers/thermal/Makefile  |  1 -
 drivers/thermal/qcom/Kconfig  | 11 +++
 drivers/thermal/qcom/Makefile |  1 +
 drivers/thermal/{ => qcom}/qcom-spmi-temp-alarm.c |  2 +-
 5 files changed, 13 insertions(+), 13 deletions(-)
 rename drivers/thermal/{ => qcom}/qcom-spmi-temp-alarm.c (99%)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 772ab9dadda7..344f6459862b 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -374,17 +374,6 @@ config TANGO_THERMAL
 
 source "drivers/thermal/tegra/Kconfig"
 
-config QCOM_SPMI_TEMP_ALARM
-   tristate "Qualcomm SPMI PMIC Temperature Alarm"
-   depends on OF && SPMI && IIO
-   select REGMAP_SPMI
-   help
- This enables a thermal sysfs driver for Qualcomm plug-and-play (QPNP)
- PMIC devices. It shows up in sysfs as a thermal sensor with multiple
- trip points. The temperature reported by the thermal sensor reflects 
the
- real time die temperature if an ADC is present or an estimate of the
- temperature based upon the over temperature stage value.
-
 config GENERIC_ADC_THERMAL
tristate "Generic ADC based thermal sensor"
depends on IIO
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 0b5d33a49b3e..486d682be047 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -29,7 +29,6 @@ thermal_sys-$(CONFIG_DEVFREQ_THERMAL) += devfreq_cooling.o
 
 # platform thermal drivers
 obj-y  += broadcom/
-obj-$(CONFIG_QCOM_SPMI_TEMP_ALARM) += qcom-spmi-temp-alarm.o
 obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
 obj-$(CONFIG_ROCKCHIP_THERMAL) += rockchip_thermal.o
 obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
diff --git a/drivers/thermal/qcom/Kconfig b/drivers/thermal/qcom/Kconfig
index be32e5abce3c..cdb455ffd575 100644
--- a/drivers/thermal/qcom/Kconfig
+++ b/drivers/thermal/qcom/Kconfig
@@ -9,3 +9,14 @@ config QCOM_TSENS
  thermal zone device via the mode file results in disabling the sensor.
  Also able to set threshold temperature for both hot and cold and 
update
  when a threshold is reached.
+
+config QCOM_SPMI_TEMP_ALARM
+   tristate "Qualcomm SPMI PMIC Temperature Alarm"
+   depends on OF && SPMI && IIO
+   select REGMAP_SPMI
+   help
+ This enables a thermal sysfs driver for Qualcomm plug-and-play (QPNP)
+ PMIC devices. It shows up in sysfs as a thermal sensor with multiple
+ trip points. The temperature reported by the thermal sensor reflects 
the
+ real time die temperature if an ADC is present or an estimate of the
+ temperature based upon the over temperature stage value.
diff --git a/drivers/thermal/qcom/Makefile b/drivers/thermal/qcom/Makefile
index a821929ede0b..717a08600bb5 100644
--- a/drivers/thermal/qcom/Makefile
+++ b/drivers/thermal/qcom/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_QCOM_TSENS)   += qcom_tsens.o
 qcom_tsens-y   += tsens.o tsens-common.o tsens-8916.o 
tsens-8974.o tsens-8960.o tsens-v2.o
+obj-$(CONFIG_QCOM_SPMI_TEMP_ALARM) += qcom-spmi-temp-alarm.o
diff --git a/drivers/thermal/qcom-spmi-temp-alarm.c 
b/drivers/thermal/qcom/qcom-spmi-temp-alarm.c
similarity index 99%
rename from drivers/thermal/qcom-spmi-temp-alarm.c
rename to drivers/thermal/qcom/qcom-spmi-temp-alarm.c
index b2d5d5bf4a9b..c1fd71dbab3e 100644
--- a/drivers/thermal/qcom-spmi-temp-alarm.c
+++ b/drivers/thermal/qcom/qcom-spmi-temp-alarm.c
@@ -23,7 +23,7 @@
 #include 
 #include 
 
-#include "thermal_core.h"
+#include "../thermal_core.h"
 
 #define QPNP_TM_REG_TYPE   0x04
 #define QPNP_TM_REG_SUBTYPE0x05
-- 
2.17.1

Re: [PATCH AUTOSEL 4.19 040/123] bpf: allocate local storage buffers using GFP_ATOMIC

[Naresh Kamboju]

On Fri, 7 Dec 2018 at 12:10, Naresh Kamboju  wrote:
>
> On Wed, 5 Dec 2018 at 15:08, Sasha Levin  wrote:
> >
> > From: Roman Gushchin 
> >
> > [ Upstream commit 569a933b03f3c48b392fe67c0086b3a6b9306b5a ]
> >
> > Naresh reported an issue with the non-atomic memory allocation of
> > cgroup local storage buffers:
> >
> > [   73.047526] BUG: sleeping function called from invalid context at
> > /srv/oe/build/tmp-rpb-glibc/work-shared/intel-corei7-64/kernel-source/mm/slab.h:421
> > [   73.060915] in_atomic(): 1, irqs_disabled(): 0, pid: 3157, name: 
> > test_cgroup_sto
> > [   73.068342] INFO: lockdep is turned off.
> > [   73.072293] CPU: 2 PID: 3157 Comm: test_cgroup_sto Not tainted
> > 4.20.0-rc2-next-20181113 #1
> > [   73.080548] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
> > 2.0b 07/27/2017
> > [   73.088018] Call Trace:
> > [   73.090463]  dump_stack+0x70/0xa5
> > [   73.093783]  ___might_sleep+0x152/0x240
> > [   73.097619]  __might_sleep+0x4a/0x80
> > [   73.101191]  __kmalloc_node+0x1cf/0x2f0
> > [   73.105031]  ? cgroup_storage_update_elem+0x46/0x90
> > [   73.109909]  cgroup_storage_update_elem+0x46/0x90
> >
> > cgroup_storage_update_elem() (as well as other update map update
> > callbacks) is called with disabled preemption, so GFP_ATOMIC
> > allocation should be used: e.g. alloc_htab_elem() in hashtab.c.
> >
> > Reported-by: Naresh Kamboju 
> > Tested-by: Naresh Kamboju 
> > Signed-off-by: Roman Gushchin 
> > Cc: Alexei Starovoitov 
> > Cc: Daniel Borkmann 
> > Signed-off-by: Alexei Starovoitov 
> > Signed-off-by: Sasha Levin 
>
> I have reported above issue on 4.20.0-rc2-next-20181113.
> Now this BUG re-occurring on 4.19.8-rc1 on x86_64 and arm64 devices.

This BUG: was seen on 4.19.1-rc1 also on x86_64 and arm64 devices.

- Naresh

RE: [PATCH v2 2/3] ALSA: hda/realtek: Enable audio jacks of ASUS UX533FD with ALC294

[Kailang]

Hi Jian Hong,

I call our agent guy @ WTMEC.
Please modify as bellowing then test again.
Remove EAPD control by hidden.
If this modify patch was pass audio test, please regenerate patch to Takashi.
If this patch will solve the speaker no sound issue, I think the model name 
maybe could rename to ALC294_FIXUP_ASUS_SPK.
Because it doesn't relate with Noise.

> +   [ALC294_FIXUP_ASUS_SPK_NOISE] = {
> +   .type = HDA_FIXUP_VERBS,
> +   .v.verbs = (const struct hda_verb[]) {
> +   { 0x20, AC_VERB_SET_COEF_INDEX, 0x40 },
> +   { 0x20, AC_VERB_SET_PROC_COEF, 0x8800 },
> +   { }
> +   },
> +   .chained = true,
> +   .chain_id = ALC294_FIXUP_ASUS_HEADSET_MIC
> +   },
>  };

BR,
Kailang

-Original Message-
From: Jian-Hong Pan  
Sent: Friday, December 7, 2018 11:48 AM
To: Kailang 
Cc: Jaroslav Kysela ; Takashi Iwai ; Hui Wang 
; alsa-de...@alsa-project.org; Linux Kernel 
; Linux Upstreaming Team ; 
Daniel Drake 
Subject: Re: [PATCH v2 2/3] ALSA: hda/realtek: Enable audio jacks of ASUS 
UX533FD with ALC294

Kailang  於 2018年12月7日 週五 上午11:32寫道：
>
> Hi Jian Hong,
>
> Could I know who give you the value as below?
>
> +   { 0x20, AC_VERB_SET_COEF_INDEX, 0x10 },
> +   { 0x20, 0x4c4, 0x20 },
> +   { 0x20, AC_VERB_SET_COEF_INDEX, 0x40 },
> +   { 0x20, 0x488, 0x00 },

A module maker.

Regards,
Jian-Hong Pan

> -Original Message-
> From: Jian-Hong Pan 
> Sent: Thursday, December 6, 2018 4:46 PM
> To: Jaroslav Kysela ; Takashi Iwai ; 
> Kailang 
> Cc: Hui Wang ; alsa-de...@alsa-project.org; 
> linux-kernel@vger.kernel.org; li...@endlessm.com; Jian-Hong Pan 
> ; Daniel Drake 
> Subject: [PATCH v2 2/3] ALSA: hda/realtek: Enable audio jacks of ASUS 
> UX533FD with ALC294
>
> The ASUS UX533FD with ALC294 cannot detect the headset MIC and output through 
> the internal speaker and the headphone until ALC294_FIXUP_ASUS_SPK_NOISE 
> quirk applied.
>
> Signed-off-by: Daniel Drake 
> Signed-off-by: Jian-Hong Pan 
> ---
> v2:
> - Modify the HDA verbs for UX333FA support
> - Make a new ALC294_FIXUP_ASUS_HEADSET_MIC quirk for ALC294 chain
> - .chain_id = ALC256_FIXUP_ASUS_HEADSET_MODE  ==> change to 
> ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
>
>  sound/pci/hda/patch_realtek.c | 25 +
>  1 file changed, 25 insertions(+)
>
> diff --git a/sound/pci/hda/patch_realtek.c 
> b/sound/pci/hda/patch_realtek.c index d32e50b1ed60..1525bcdf96e8 
> 100644
> --- a/sound/pci/hda/patch_realtek.c
> +++ b/sound/pci/hda/patch_realtek.c
> @@ -5518,6 +5518,8 @@ enum {
> ALC295_FIXUP_HP_AUTO_MUTE,
> ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE,
> ALC294_FIXUP_ASUS_MIC,
> +   ALC294_FIXUP_ASUS_HEADSET_MIC,
> +   ALC294_FIXUP_ASUS_SPK_NOISE,
>  };
>
>  static const struct hda_fixup alc269_fixups[] = { @@ -6414,6 +6416,28 @@ 
> static const struct hda_fixup alc269_fixups[] = {
> .chained = true,
> .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
> },
> +   [ALC294_FIXUP_ASUS_HEADSET_MIC] = {
> +   .type = HDA_FIXUP_PINS,
> +   .v.pins = (const struct hda_pintbl[]) {
> +   { 0x19, 0x01a1113c }, /* use as headset mic, without 
> its own jack detect */
> +   { }
> +   },
> +   .chained = true,
> +   .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
> +   },
> +   [ALC294_FIXUP_ASUS_SPK_NOISE] = {
> +   .type = HDA_FIXUP_VERBS,
> +   .v.verbs = (const struct hda_verb[]) {
> +   /* Set EAPD high */
> +   { 0x20, AC_VERB_SET_COEF_INDEX, 0x10 },
> +   { 0x20, 0x4c4, 0x20 },
> +   { 0x20, AC_VERB_SET_COEF_INDEX, 0x40 },
> +   { 0x20, 0x488, 0x00 },
> +   { }
> +   },
> +   .chained = true,
> +   .chain_id = ALC294_FIXUP_ASUS_HEADSET_MIC
> +   },
>  };
>
>  static const struct snd_pci_quirk alc269_fixup_tbl[] = { @@ -6556,6 +6580,7 
> @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
> SND_PCI_QUIRK(0x1043, 0x12e0, "ASUS X541SA", ALC256_FIXUP_ASUS_MIC),
> SND_PCI_QUIRK(0x1043, 0x13b0, "ASUS Z550SA", ALC256_FIXUP_ASUS_MIC),
> SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", 
> ALC269VB_FIXUP_ASUS_ZENBOOK),
> +   SND_PCI_QUIRK(0x1043, 0x14a1, "ASUS UX533FD", 
> +ALC294_FIXUP_ASUS_SPK_NOISE),
> SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A", 
> ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),
> SND_PCI_QUIRK(0x1043, 0x16e3, "ASUS UX50", ALC269_FIXUP_STEREO_DMIC),
> SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", 
> ALC269_FIXUP_ASUS_G73JW),
> --
> 2.11.0
>

--Please consider the environment before printing this e-mail.

RE: [PATCH v2 2/3] ALSA: hda/realtek: Enable audio jacks of ASUS UX533FD with ALC294

[Kailang]

Hi Jian Hong,

I call our agent guy @ WTMEC.
Please modify as bellowing then test again.
Remove EAPD control by hidden.
If this modify patch was pass audio test, please regenerate patch to Takashi.
If this patch will solve the speaker no sound issue, I think the model name 
maybe could rename to ALC294_FIXUP_ASUS_SPK.
Because it doesn't relate with Noise.

> +   [ALC294_FIXUP_ASUS_SPK_NOISE] = {
> +   .type = HDA_FIXUP_VERBS,
> +   .v.verbs = (const struct hda_verb[]) {
> +   { 0x20, AC_VERB_SET_COEF_INDEX, 0x40 },
> +   { 0x20, AC_VERB_SET_PROC_COEF, 0x8800 },
> +   { }
> +   },
> +   .chained = true,
> +   .chain_id = ALC294_FIXUP_ASUS_HEADSET_MIC
> +   },
>  };

BR,
Kailang

-Original Message-
From: Jian-Hong Pan  
Sent: Friday, December 7, 2018 11:48 AM
To: Kailang 
Cc: Jaroslav Kysela ; Takashi Iwai ; Hui Wang 
; alsa-de...@alsa-project.org; Linux Kernel 
; Linux Upstreaming Team ; 
Daniel Drake 
Subject: Re: [PATCH v2 2/3] ALSA: hda/realtek: Enable audio jacks of ASUS 
UX533FD with ALC294

Kailang  於 2018年12月7日 週五 上午11:32寫道：
>
> Hi Jian Hong,
>
> Could I know who give you the value as below?
>
> +   { 0x20, AC_VERB_SET_COEF_INDEX, 0x10 },
> +   { 0x20, 0x4c4, 0x20 },
> +   { 0x20, AC_VERB_SET_COEF_INDEX, 0x40 },
> +   { 0x20, 0x488, 0x00 },

A module maker.

Regards,
Jian-Hong Pan

> -Original Message-
> From: Jian-Hong Pan 
> Sent: Thursday, December 6, 2018 4:46 PM
> To: Jaroslav Kysela ; Takashi Iwai ; 
> Kailang 
> Cc: Hui Wang ; alsa-de...@alsa-project.org; 
> linux-kernel@vger.kernel.org; li...@endlessm.com; Jian-Hong Pan 
> ; Daniel Drake 
> Subject: [PATCH v2 2/3] ALSA: hda/realtek: Enable audio jacks of ASUS 
> UX533FD with ALC294
>
> The ASUS UX533FD with ALC294 cannot detect the headset MIC and output through 
> the internal speaker and the headphone until ALC294_FIXUP_ASUS_SPK_NOISE 
> quirk applied.
>
> Signed-off-by: Daniel Drake 
> Signed-off-by: Jian-Hong Pan 
> ---
> v2:
> - Modify the HDA verbs for UX333FA support
> - Make a new ALC294_FIXUP_ASUS_HEADSET_MIC quirk for ALC294 chain
> - .chain_id = ALC256_FIXUP_ASUS_HEADSET_MODE  ==> change to 
> ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
>
>  sound/pci/hda/patch_realtek.c | 25 +
>  1 file changed, 25 insertions(+)
>
> diff --git a/sound/pci/hda/patch_realtek.c 
> b/sound/pci/hda/patch_realtek.c index d32e50b1ed60..1525bcdf96e8 
> 100644
> --- a/sound/pci/hda/patch_realtek.c
> +++ b/sound/pci/hda/patch_realtek.c
> @@ -5518,6 +5518,8 @@ enum {
> ALC295_FIXUP_HP_AUTO_MUTE,
> ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE,
> ALC294_FIXUP_ASUS_MIC,
> +   ALC294_FIXUP_ASUS_HEADSET_MIC,
> +   ALC294_FIXUP_ASUS_SPK_NOISE,
>  };
>
>  static const struct hda_fixup alc269_fixups[] = { @@ -6414,6 +6416,28 @@ 
> static const struct hda_fixup alc269_fixups[] = {
> .chained = true,
> .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
> },
> +   [ALC294_FIXUP_ASUS_HEADSET_MIC] = {
> +   .type = HDA_FIXUP_PINS,
> +   .v.pins = (const struct hda_pintbl[]) {
> +   { 0x19, 0x01a1113c }, /* use as headset mic, without 
> its own jack detect */
> +   { }
> +   },
> +   .chained = true,
> +   .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
> +   },
> +   [ALC294_FIXUP_ASUS_SPK_NOISE] = {
> +   .type = HDA_FIXUP_VERBS,
> +   .v.verbs = (const struct hda_verb[]) {
> +   /* Set EAPD high */
> +   { 0x20, AC_VERB_SET_COEF_INDEX, 0x10 },
> +   { 0x20, 0x4c4, 0x20 },
> +   { 0x20, AC_VERB_SET_COEF_INDEX, 0x40 },
> +   { 0x20, 0x488, 0x00 },
> +   { }
> +   },
> +   .chained = true,
> +   .chain_id = ALC294_FIXUP_ASUS_HEADSET_MIC
> +   },
>  };
>
>  static const struct snd_pci_quirk alc269_fixup_tbl[] = { @@ -6556,6 +6580,7 
> @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
> SND_PCI_QUIRK(0x1043, 0x12e0, "ASUS X541SA", ALC256_FIXUP_ASUS_MIC),
> SND_PCI_QUIRK(0x1043, 0x13b0, "ASUS Z550SA", ALC256_FIXUP_ASUS_MIC),
> SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", 
> ALC269VB_FIXUP_ASUS_ZENBOOK),
> +   SND_PCI_QUIRK(0x1043, 0x14a1, "ASUS UX533FD", 
> +ALC294_FIXUP_ASUS_SPK_NOISE),
> SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A", 
> ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),
> SND_PCI_QUIRK(0x1043, 0x16e3, "ASUS UX50", ALC269_FIXUP_STEREO_DMIC),
> SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", 
> ALC269_FIXUP_ASUS_G73JW),
> --
> 2.11.0
>

--Please consider the environment before printing this e-mail.

Re: [PATCH 4.19 00/41] 4.19.8-stable review

[Greg Kroah-Hartman]

On Thu, Dec 06, 2018 at 03:10:03PM -0700, shuah wrote:
> On 12/6/18 7:38 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.19.8 release.
> > There are 41 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sat Dec  8 14:29:30 UTC 2018.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.8-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.19.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing and letting me know.

greg k-h

Re: [PATCH 4.19 00/41] 4.19.8-stable review

[Greg Kroah-Hartman]

On Thu, Dec 06, 2018 at 03:10:03PM -0700, shuah wrote:
> On 12/6/18 7:38 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.19.8 release.
> > There are 41 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sat Dec  8 14:29:30 UTC 2018.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.8-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.19.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing and letting me know.

greg k-h

[PATCH v3 0/2] add SAMA5D2 PIOBU GPIO driver

[Andrei.Stefanescu]

On SAMA5D2 SoC the PIOBU pins do not lose their
voltage during Backup/Self-refresh mode. This can
be useful, for example, when the voltage must remain
positive for a peripheral during Backup/Self-refresh
mode (suspend-to ram is the Linux equivalent state).

v3:
- change driver's compatible to atmel,sama5d2-secumod
- get syscon using syscon_node_to_regmap(pdev->dev.of_node)
- document how to use SECUMOD as a gpio-controller

v2:
- make driver be a subnode of the syscon node
- change Kconfig to depend on MFD_SYSCON and select GPIO_SYSCON
- change include header from linux/gpio.h to linux/gpio/driver.h
- include linux/bits.h header
- change intrusion in comment to tamper
- fix kerneldoc of functions
- replace GPIOF_DIR_* flags with 0/1
- replace ?: statement with if-else
- remove the use of sama5d2_piobu_template_chip
- retrieve syscon via syscon_node_to_regmap(pdev->dev.parent->of_node);

Note that PIOBU_REG_SIZE is used to determine the register to write to
with regmap:
reg = PIOBU_BASE + pin * PIOBU_REG_SIZE;

Also, no irq capability implemented.

Andrei Stefanescu (2):
  dt-bindings: arm: atmel: describe SECUMOD usage as a GPIO controller
  gpio: add driver for SAMA5D2 PIOBU pins

 .../devicetree/bindings/arm/atmel-sysregs.txt  |  12 +-
 MAINTAINERS|   6 +
 drivers/gpio/gpio-sama5d2-piobu.c  | 253 +
 3 files changed, 270 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpio/gpio-sama5d2-piobu.c

-- 
2.7.4

[PATCH v3 0/2] add SAMA5D2 PIOBU GPIO driver

[Andrei.Stefanescu]

On SAMA5D2 SoC the PIOBU pins do not lose their
voltage during Backup/Self-refresh mode. This can
be useful, for example, when the voltage must remain
positive for a peripheral during Backup/Self-refresh
mode (suspend-to ram is the Linux equivalent state).

v3:
- change driver's compatible to atmel,sama5d2-secumod
- get syscon using syscon_node_to_regmap(pdev->dev.of_node)
- document how to use SECUMOD as a gpio-controller

v2:
- make driver be a subnode of the syscon node
- change Kconfig to depend on MFD_SYSCON and select GPIO_SYSCON
- change include header from linux/gpio.h to linux/gpio/driver.h
- include linux/bits.h header
- change intrusion in comment to tamper
- fix kerneldoc of functions
- replace GPIOF_DIR_* flags with 0/1
- replace ?: statement with if-else
- remove the use of sama5d2_piobu_template_chip
- retrieve syscon via syscon_node_to_regmap(pdev->dev.parent->of_node);

Note that PIOBU_REG_SIZE is used to determine the register to write to
with regmap:
reg = PIOBU_BASE + pin * PIOBU_REG_SIZE;

Also, no irq capability implemented.

Andrei Stefanescu (2):
  dt-bindings: arm: atmel: describe SECUMOD usage as a GPIO controller
  gpio: add driver for SAMA5D2 PIOBU pins

 .../devicetree/bindings/arm/atmel-sysregs.txt  |  12 +-
 MAINTAINERS|   6 +
 drivers/gpio/gpio-sama5d2-piobu.c  | 253 +
 3 files changed, 270 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpio/gpio-sama5d2-piobu.c

-- 
2.7.4

[PATCH v3 1/2] dt-bindings: arm: atmel: describe SECUMOD usage as a GPIO controller

[Andrei.Stefanescu]

This patch describes the Security Module's usage as a GPIO
controller for its PIOBU pins. These pins have the special
property of maintaining their voltage during suspend-to-mem.

Signed-off-by: Andrei Stefanescu 
---
 Documentation/devicetree/bindings/arm/atmel-sysregs.txt | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt 
b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
index 4b96608..c89db84 100644
--- a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
@@ -158,14 +158,24 @@ Security Module (SECUMOD)
 
 The Security Module macrocell provides all necessary secure functions to avoid
 voltage, temperature, frequency and mechanical attacks on the chip. It also
-embeds secure memories that can be scrambled
+embeds secure memories that can be scrambled.
+
+The Security Module also offers the PIOBU pins which can be used as GPIO pins.
+Note that they maintain their voltage during Backup/Self-refresh. 
 
 required properties:
 - compatible: Should be "atmel,-secumod", "syscon".
can be "sama5d2".
 - reg: Should contain registers location and length
+- gpio-controller: Marks the port as GPIO controller.
+- #gpio-cells: There are 2. The pin number is the
+   first, the second represents additional
+   parameters such as GPIO_ACTIVE_HIGH/LOW.
+
 
secumod@fc04 {
compatible = "atmel,sama5d2-secumod", "syscon";
reg = <0xfc04 0x100>;
+   gpio-controller;
+   #gpio-cells = <2>;
};
-- 
2.7.4

[PATCH v3 2/2] gpio: add driver for SAMA5D2 PIOBU pins

[Andrei.Stefanescu]

PIOBU pins do not lose their voltage during Backup/Self-refresh.
This patch adds a simple GPIO controller for them and a
maintainer for the driver.

This driver adds support for using the pins as GPIO
offering the possibility to read/set the voltage.

Signed-off-by: Andrei Stefanescu 
---
 MAINTAINERS   |   6 +
 drivers/gpio/gpio-sama5d2-piobu.c | 253 ++
 2 files changed, 259 insertions(+)
 create mode 100644 drivers/gpio/gpio-sama5d2-piobu.c

diff --git a/MAINTAINERS b/MAINTAINERS
index f485597..fadc96d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9760,6 +9760,12 @@ M:   Nicolas Ferre 
 S: Supported
 F: drivers/power/reset/at91-sama5d2_shdwc.c
 
+MICROCHIP SAMA5D2-COMPATIBLE PIOBU GPIO
+M: Andrei Stefanescu 
+L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
+L: linux-g...@vger.kernel.org
+F: drivers/gpio/gpio-sama5d2-piobu.c
+
 MICROCHIP SPI DRIVER
 M: Nicolas Ferre 
 S: Supported
diff --git a/drivers/gpio/gpio-sama5d2-piobu.c 
b/drivers/gpio/gpio-sama5d2-piobu.c
new file mode 100644
index 000..03a0006
--- /dev/null
+++ b/drivers/gpio/gpio-sama5d2-piobu.c
@@ -0,0 +1,253 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * SAMA5D2 PIOBU GPIO controller
+ *
+ * Copyright (C) 2018 Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Andrei Stefanescu 
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PIOBU_NUM 8
+#define PIOBU_REG_SIZE 4
+
+/*
+ * backup mode protection register for tamper detection
+ * normal mode protection register for tamper detection
+ * wakeup signal generation
+ */
+#define PIOBU_BMPR 0x7C
+#define PIOBU_NMPR 0x80
+#define PIOBU_WKPR 0x90
+
+#define PIOBU_BASE 0x18 /* PIOBU offset from SECUMOD base register address. */
+
+#define PIOBU_DET_OFFSET 16
+
+/* In the datasheet this bit is called OUTPUT */
+#define PIOBU_DIRECTION BIT(8)
+#define PIOBU_OUT BIT(8)
+#define PIOBU_IN 0
+
+#define PIOBU_SOD BIT(9)
+#define PIOBU_PDS BIT(10)
+
+#define PIOBU_HIGH BIT(9)
+#define PIOBU_LOW 0
+
+struct sama5d2_piobu {
+   struct gpio_chip chip;
+   struct regmap *regmap;
+};
+
+/**
+ * sama5d2_piobu_setup_pin() - prepares a pin for set_direction call
+ *
+ * Do not consider pin for tamper detection (normal and backup modes)
+ * Do not consider pin as tamper wakeup interrupt source
+ */
+static int sama5d2_piobu_setup_pin(struct gpio_chip *chip, unsigned int pin)
+{
+   int ret;
+   struct sama5d2_piobu *piobu = container_of(chip, struct sama5d2_piobu,
+  chip);
+   unsigned int mask = BIT(PIOBU_DET_OFFSET + pin);
+
+   ret = regmap_update_bits(piobu->regmap, PIOBU_BMPR, mask, 0);
+   if (ret)
+   return ret;
+
+   ret = regmap_update_bits(piobu->regmap, PIOBU_NMPR, mask, 0);
+   if (ret)
+   return ret;
+
+   return regmap_update_bits(piobu->regmap, PIOBU_WKPR, mask, 0);
+}
+
+/**
+ * sama5d2_piobu_write_value() - writes value & mask at the pin's PIOBU 
register
+ */
+static int sama5d2_piobu_write_value(struct gpio_chip *chip, unsigned int pin,
+unsigned int mask, unsigned int value)
+{
+   int reg;
+   struct sama5d2_piobu *piobu = container_of(chip, struct sama5d2_piobu,
+  chip);
+
+   reg = PIOBU_BASE + pin * PIOBU_REG_SIZE;
+
+   return regmap_update_bits(piobu->regmap, reg, mask, value);
+}
+
+/**
+ * sama5d2_piobu_read_value() - read the value with masking from the pin's 
PIOBU
+ *   register
+ */
+static int sama5d2_piobu_read_value(struct gpio_chip *chip, unsigned int pin,
+   unsigned int mask)
+{
+   struct sama5d2_piobu *piobu = container_of(chip, struct sama5d2_piobu,
+  chip);
+   unsigned int val, reg;
+   int ret;
+
+   reg = PIOBU_BASE + pin * PIOBU_REG_SIZE;
+   ret = regmap_read(piobu->regmap, reg, );
+   if (ret < 0)
+   return ret;
+
+   return val & mask;
+}
+
+/**
+ * sama5d2_piobu_set_direction() - mark pin as input or output
+ */
+static int sama5d2_piobu_set_direction(struct gpio_chip *chip,
+  unsigned int direction,
+  unsigned int pin)
+{
+   return sama5d2_piobu_write_value(chip, pin, PIOBU_DIRECTION, direction);
+}
+
+/**
+ * sama5d2_piobu_get_direction() - gpiochip get_direction
+ */
+static int sama5d2_piobu_get_direction(struct gpio_chip *chip,
+  unsigned int pin)
+{
+   int ret = sama5d2_piobu_read_value(chip, pin, PIOBU_DIRECTION);
+
+   if (ret < 0)
+   return ret;
+
+   return (ret == PIOBU_IN) ? 1 : 0;
+}
+
+/**
+ * sama5d2_piobu_direction_input() - gpiochip direction_input
+ */

[PATCH v3 1/2] dt-bindings: arm: atmel: describe SECUMOD usage as a GPIO controller

[Andrei.Stefanescu]

This patch describes the Security Module's usage as a GPIO
controller for its PIOBU pins. These pins have the special
property of maintaining their voltage during suspend-to-mem.

Signed-off-by: Andrei Stefanescu 
---
 Documentation/devicetree/bindings/arm/atmel-sysregs.txt | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt 
b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
index 4b96608..c89db84 100644
--- a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
@@ -158,14 +158,24 @@ Security Module (SECUMOD)
 
 The Security Module macrocell provides all necessary secure functions to avoid
 voltage, temperature, frequency and mechanical attacks on the chip. It also
-embeds secure memories that can be scrambled
+embeds secure memories that can be scrambled.
+
+The Security Module also offers the PIOBU pins which can be used as GPIO pins.
+Note that they maintain their voltage during Backup/Self-refresh. 
 
 required properties:
 - compatible: Should be "atmel,-secumod", "syscon".
can be "sama5d2".
 - reg: Should contain registers location and length
+- gpio-controller: Marks the port as GPIO controller.
+- #gpio-cells: There are 2. The pin number is the
+   first, the second represents additional
+   parameters such as GPIO_ACTIVE_HIGH/LOW.
+
 
secumod@fc04 {
compatible = "atmel,sama5d2-secumod", "syscon";
reg = <0xfc04 0x100>;
+   gpio-controller;
+   #gpio-cells = <2>;
};
-- 
2.7.4

[PATCH v3 2/2] gpio: add driver for SAMA5D2 PIOBU pins

[Andrei.Stefanescu]

PIOBU pins do not lose their voltage during Backup/Self-refresh.
This patch adds a simple GPIO controller for them and a
maintainer for the driver.

This driver adds support for using the pins as GPIO
offering the possibility to read/set the voltage.

Signed-off-by: Andrei Stefanescu 
---
 MAINTAINERS   |   6 +
 drivers/gpio/gpio-sama5d2-piobu.c | 253 ++
 2 files changed, 259 insertions(+)
 create mode 100644 drivers/gpio/gpio-sama5d2-piobu.c

diff --git a/MAINTAINERS b/MAINTAINERS
index f485597..fadc96d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9760,6 +9760,12 @@ M:   Nicolas Ferre 
 S: Supported
 F: drivers/power/reset/at91-sama5d2_shdwc.c
 
+MICROCHIP SAMA5D2-COMPATIBLE PIOBU GPIO
+M: Andrei Stefanescu 
+L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
+L: linux-g...@vger.kernel.org
+F: drivers/gpio/gpio-sama5d2-piobu.c
+
 MICROCHIP SPI DRIVER
 M: Nicolas Ferre 
 S: Supported
diff --git a/drivers/gpio/gpio-sama5d2-piobu.c 
b/drivers/gpio/gpio-sama5d2-piobu.c
new file mode 100644
index 000..03a0006
--- /dev/null
+++ b/drivers/gpio/gpio-sama5d2-piobu.c
@@ -0,0 +1,253 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * SAMA5D2 PIOBU GPIO controller
+ *
+ * Copyright (C) 2018 Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Andrei Stefanescu 
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PIOBU_NUM 8
+#define PIOBU_REG_SIZE 4
+
+/*
+ * backup mode protection register for tamper detection
+ * normal mode protection register for tamper detection
+ * wakeup signal generation
+ */
+#define PIOBU_BMPR 0x7C
+#define PIOBU_NMPR 0x80
+#define PIOBU_WKPR 0x90
+
+#define PIOBU_BASE 0x18 /* PIOBU offset from SECUMOD base register address. */
+
+#define PIOBU_DET_OFFSET 16
+
+/* In the datasheet this bit is called OUTPUT */
+#define PIOBU_DIRECTION BIT(8)
+#define PIOBU_OUT BIT(8)
+#define PIOBU_IN 0
+
+#define PIOBU_SOD BIT(9)
+#define PIOBU_PDS BIT(10)
+
+#define PIOBU_HIGH BIT(9)
+#define PIOBU_LOW 0
+
+struct sama5d2_piobu {
+   struct gpio_chip chip;
+   struct regmap *regmap;
+};
+
+/**
+ * sama5d2_piobu_setup_pin() - prepares a pin for set_direction call
+ *
+ * Do not consider pin for tamper detection (normal and backup modes)
+ * Do not consider pin as tamper wakeup interrupt source
+ */
+static int sama5d2_piobu_setup_pin(struct gpio_chip *chip, unsigned int pin)
+{
+   int ret;
+   struct sama5d2_piobu *piobu = container_of(chip, struct sama5d2_piobu,
+  chip);
+   unsigned int mask = BIT(PIOBU_DET_OFFSET + pin);
+
+   ret = regmap_update_bits(piobu->regmap, PIOBU_BMPR, mask, 0);
+   if (ret)
+   return ret;
+
+   ret = regmap_update_bits(piobu->regmap, PIOBU_NMPR, mask, 0);
+   if (ret)
+   return ret;
+
+   return regmap_update_bits(piobu->regmap, PIOBU_WKPR, mask, 0);
+}
+
+/**
+ * sama5d2_piobu_write_value() - writes value & mask at the pin's PIOBU 
register
+ */
+static int sama5d2_piobu_write_value(struct gpio_chip *chip, unsigned int pin,
+unsigned int mask, unsigned int value)
+{
+   int reg;
+   struct sama5d2_piobu *piobu = container_of(chip, struct sama5d2_piobu,
+  chip);
+
+   reg = PIOBU_BASE + pin * PIOBU_REG_SIZE;
+
+   return regmap_update_bits(piobu->regmap, reg, mask, value);
+}
+
+/**
+ * sama5d2_piobu_read_value() - read the value with masking from the pin's 
PIOBU
+ *   register
+ */
+static int sama5d2_piobu_read_value(struct gpio_chip *chip, unsigned int pin,
+   unsigned int mask)
+{
+   struct sama5d2_piobu *piobu = container_of(chip, struct sama5d2_piobu,
+  chip);
+   unsigned int val, reg;
+   int ret;
+
+   reg = PIOBU_BASE + pin * PIOBU_REG_SIZE;
+   ret = regmap_read(piobu->regmap, reg, );
+   if (ret < 0)
+   return ret;
+
+   return val & mask;
+}
+
+/**
+ * sama5d2_piobu_set_direction() - mark pin as input or output
+ */
+static int sama5d2_piobu_set_direction(struct gpio_chip *chip,
+  unsigned int direction,
+  unsigned int pin)
+{
+   return sama5d2_piobu_write_value(chip, pin, PIOBU_DIRECTION, direction);
+}
+
+/**
+ * sama5d2_piobu_get_direction() - gpiochip get_direction
+ */
+static int sama5d2_piobu_get_direction(struct gpio_chip *chip,
+  unsigned int pin)
+{
+   int ret = sama5d2_piobu_read_value(chip, pin, PIOBU_DIRECTION);
+
+   if (ret < 0)
+   return ret;
+
+   return (ret == PIOBU_IN) ? 1 : 0;
+}
+
+/**
+ * sama5d2_piobu_direction_input() - gpiochip direction_input
+ */

Re: [PATCH AUTOSEL 4.19 040/123] bpf: allocate local storage buffers using GFP_ATOMIC

[Naresh Kamboju]

On Wed, 5 Dec 2018 at 15:08, Sasha Levin  wrote:
>
> From: Roman Gushchin 
>
> [ Upstream commit 569a933b03f3c48b392fe67c0086b3a6b9306b5a ]
>
> Naresh reported an issue with the non-atomic memory allocation of
> cgroup local storage buffers:
>
> [   73.047526] BUG: sleeping function called from invalid context at
> /srv/oe/build/tmp-rpb-glibc/work-shared/intel-corei7-64/kernel-source/mm/slab.h:421
> [   73.060915] in_atomic(): 1, irqs_disabled(): 0, pid: 3157, name: 
> test_cgroup_sto
> [   73.068342] INFO: lockdep is turned off.
> [   73.072293] CPU: 2 PID: 3157 Comm: test_cgroup_sto Not tainted
> 4.20.0-rc2-next-20181113 #1
> [   73.080548] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
> 2.0b 07/27/2017
> [   73.088018] Call Trace:
> [   73.090463]  dump_stack+0x70/0xa5
> [   73.093783]  ___might_sleep+0x152/0x240
> [   73.097619]  __might_sleep+0x4a/0x80
> [   73.101191]  __kmalloc_node+0x1cf/0x2f0
> [   73.105031]  ? cgroup_storage_update_elem+0x46/0x90
> [   73.109909]  cgroup_storage_update_elem+0x46/0x90
>
> cgroup_storage_update_elem() (as well as other update map update
> callbacks) is called with disabled preemption, so GFP_ATOMIC
> allocation should be used: e.g. alloc_htab_elem() in hashtab.c.
>
> Reported-by: Naresh Kamboju 
> Tested-by: Naresh Kamboju 
> Signed-off-by: Roman Gushchin 
> Cc: Alexei Starovoitov 
> Cc: Daniel Borkmann 
> Signed-off-by: Alexei Starovoitov 
> Signed-off-by: Sasha Levin 

I have reported above issue on 4.20.0-rc2-next-20181113.
Now this BUG re-occurring on 4.19.8-rc1 on x86_64 and arm64 devices.

[   70.288592] BUG: sleeping function called from invalid context at
/srv/oe/build/tmp-rpb-glibc/work-shared/intel-corei7-64/kernel-source/mm/slab.h:421
[   70.301992] in_atomic(): 1, irqs_disabled(): 0, pid: 3001, name:
test_cgroup_sto
[   70.309424] INFO: lockdep is turned off.
[   70.313416] CPU: 0 PID: 3001 Comm: test_cgroup_sto Not tainted 4.19.8-rc1 #1
[   70.320483] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.0b 07/27/2017
[   70.327953] Call Trace:
[   70.330402]  dump_stack+0x70/0xa5
[   70.333765]  ___might_sleep+0x152/0x240
[   70.337599]  __might_sleep+0x4a/0x80
[   70.341169]  __kmalloc_node+0x1d1/0x300
[   70.345003]  ? cgroup_storage_update_elem+0x46/0x90
[   70.349881]  cgroup_storage_update_elem+0x46/0x90
[   70.354585]  map_update_elem+0x1fd/0x450
[   70.358504]  __x64_sys_bpf+0x129/0x270
[   70.362258]  do_syscall_64+0x55/0x190
[   70.365923]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[   70.370974] RIP: 0033:0x7f42e0ebb969
[   70.374544] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00
00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24
08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d df e4 2b 00 f7 d8 64 89
01 48
[   70.393281] RSP: 002b:7ffde61a0a08 EFLAGS: 0202 ORIG_RAX:
0141
[   70.400845] RAX: ffda RBX: 0003 RCX: 7f42e0ebb969
[   70.407971] RDX: 0048 RSI: 7ffde61a0a50 RDI: 0002
[   70.415094] RBP: 7ffde61a0a20 R08: 7ffde61a0a50 R09: 7ffde61a0a50
[   70.422216] R10: 7ffde61a0a50 R11: 0202 R12: 0005
[   70.429342] R13: 7ffde61a0c10 R14:  R15: 
selftests: bpf: test_cgroup_storage

Full test log links,
arm64 Juno
https://lkft.validation.linaro.org/scheduler/job/537820#L2971

x86_64 Supermicro SYS-5019S-ML/X11SSH-F
https://lkft.validation.linaro.org/scheduler/job/537772#L2724

Best regards
Naresh Kamboju

> ---
>  kernel/bpf/local_storage.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/local_storage.c b/kernel/bpf/local_storage.c
> index 830d7f095748..fc1605aee5ea 100644
> --- a/kernel/bpf/local_storage.c
> +++ b/kernel/bpf/local_storage.c
> @@ -138,7 +138,8 @@ static int cgroup_storage_update_elem(struct bpf_map 
> *map, void *_key,
> return -ENOENT;
>
> new = kmalloc_node(sizeof(struct bpf_storage_buffer) +
> -  map->value_size, __GFP_ZERO | GFP_USER,
> +  map->value_size,
> +  __GFP_ZERO | GFP_ATOMIC | __GFP_NOWARN,
>map->numa_node);
> if (!new)
> return -ENOMEM;
> --
> 2.17.1
>

[PATCH -next] powerpc/mm: drop test in pp_601

[YueHaibing]

The test selects between two identical values, so it doesn't look useful.
It turns out that the tested expression can only be true anyway, so drop
the test, the corresponding parameter, and the corresponding argument at
the only call site.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
expression e,e1;
@@

* e ? e1 : e1
// 

Signed-off-by: YueHaibing 
---
 arch/powerpc/mm/dump_bats.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/mm/dump_bats.c b/arch/powerpc/mm/dump_bats.c
index a0d23e9..33450a8 100644
--- a/arch/powerpc/mm/dump_bats.c
+++ b/arch/powerpc/mm/dump_bats.c
@@ -17,8 +17,8 @@ static char *pp_601(int k, int pp)
if (pp == 1)
return k ? "ROX" : "RWX";
if (pp == 2)
-   return k ? "RWX" : "RWX";
-   return k ? "ROX" : "ROX";
+   return "RWX";
+   return "ROX";
 }
 
 static void bat_show_601(struct seq_file *m, int idx, u32 lower, u32 upper)

Re: [PATCH RFC 1/1] swiotlb: add debugfs to track swiotlb buffer usage

[Joe Jin]

On 12/6/18 9:49 PM, Dongli Zhang wrote:
> 
> 
> On 12/07/2018 12:12 AM, Joe Jin wrote:
>> Hi Dongli,
>>
>> Maybe move d_swiotlb_usage declare into swiotlb_create_debugfs():
> 
> I assume the call of swiotlb_tbl_map_single() might be frequent in some
> situations, e.g., when 'swiotlb=force'.
> 
> That's why I declare the d_swiotlb_usage out of any functions and use "if
> (unlikely(!d_swiotlb_usage))".

This is reasonable.

Thanks,
Joe

> 
> I think "if (unlikely(!d_swiotlb_usage))" incur less performance overhead than
> calling swiotlb_create_debugfs() every time to confirm if debugfs is created. 
> I
> would declare d_swiotlb_usage statically inside swiotlb_create_debugfs() if 
> the
> performance overhead is acceptable (it is trivial indeed).
> 
> 
> That is the reason I tag the patch with RFC because I am not sure if the
> on-demand creation of debugfs is fine with maintainers/reviewers. If swiotlb
> pages are never allocated, we would not be able to see the debugfs entry.
> 
> I would prefer to limit the modification within swiotlb and to not taint any
> other files.
> 
> The drawback is there is no place to create or delete the debugfs entry 
> because
> swiotlb buffer could be initialized and uninitialized at very early stage.
> 
>>
>> void swiotlb_create_debugfs(void)
>> {
>> #ifdef CONFIG_DEBUG_FS
>>  static struct dentry *d_swiotlb_usage = NULL;
>>
>>  if (d_swiotlb_usage)
>>  return;
>>
>>  d_swiotlb_usage = debugfs_create_dir("swiotlb", NULL);
>>
>>  if (!d_swiotlb_usage)
>>  return;
>>
>>  debugfs_create_file("usage", 0600, d_swiotlb_usage,
>>  NULL, _usage_fops);
>> #endif
>> }
>>
>> And for io_tlb_used, possible add a check at the begin of 
>> swiotlb_tbl_map_single(),
>> if there were not any free slots or not enough slots, return fail directly?
> 
> This would optimize the slots allocation path. I will follow this in next
> version after I got more suggestions and confirmations from maintainers.
> 
> 
> Thank you very much!
> 
> Dongli Zhang
> 
>>
>> Thanks,
>> Joe
>> On 12/5/18 7:59 PM, Dongli Zhang wrote:
>>> The device driver will not be able to do dma operations once swiotlb buffer
>>> is full, either because the driver is using so many IO TLB blocks inflight,
>>> or because there is memory leak issue in device driver. To export the
>>> swiotlb buffer usage via debugfs would help the user estimate the size of
>>> swiotlb buffer to pre-allocate or analyze device driver memory leak issue.
>>>
>>> As the swiotlb can be initialized at very early stage when debugfs cannot
>>> register successfully, this patch creates the debugfs entry on demand.
>>>
>>> Signed-off-by: Dongli Zhang 
>>> ---
>>>  kernel/dma/swiotlb.c | 57 
>>> 
>>>  1 file changed, 57 insertions(+)
>>>
>>> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
>>> index 045930e..d3c8aa4 100644
>>> --- a/kernel/dma/swiotlb.c
>>> +++ b/kernel/dma/swiotlb.c
>>> @@ -35,6 +35,9 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#ifdef CONFIG_DEBUG_FS
>>> +#include 
>>> +#endif
>>>  
>>>  #include 
>>>  #include 
>>> @@ -73,6 +76,13 @@ static phys_addr_t io_tlb_start, io_tlb_end;
>>>   */
>>>  static unsigned long io_tlb_nslabs;
>>>  
>>> +#ifdef CONFIG_DEBUG_FS
>>> +/*
>>> + * The number of used IO TLB block
>>> + */
>>> +static unsigned long io_tlb_used;
>>> +#endif
>>> +
>>>  /*
>>>   * This is a free list describing the number of free entries available from
>>>   * each index
>>> @@ -100,6 +110,41 @@ static DEFINE_SPINLOCK(io_tlb_lock);
>>>  
>>>  static int late_alloc;
>>>  
>>> +#ifdef CONFIG_DEBUG_FS
>>> +
>>> +static struct dentry *d_swiotlb_usage;
>>> +
>>> +static int swiotlb_usage_show(struct seq_file *m, void *v)
>>> +{
>>> +   seq_printf(m, "%lu\n%lu\n", io_tlb_used, io_tlb_nslabs);
>>> +   return 0;
>>> +}
>>> +
>>> +static int swiotlb_usage_open(struct inode *inode, struct file *filp)
>>> +{
>>> +   return single_open(filp, swiotlb_usage_show, NULL);
>>> +}
>>> +
>>> +static const struct file_operations swiotlb_usage_fops = {
>>> +   .open   = swiotlb_usage_open,
>>> +   .read   = seq_read,
>>> +   .llseek = seq_lseek,
>>> +   .release= single_release,
>>> +};
>>> +
>>> +void swiotlb_create_debugfs(void)
>>> +{
>>> +   d_swiotlb_usage = debugfs_create_dir("swiotlb", NULL);
>>> +
>>> +   if (!d_swiotlb_usage)
>>> +   return;
>>> +
>>> +   debugfs_create_file("usage", 0600, d_swiotlb_usage,
>>> +   NULL, _usage_fops);
>>> +}
>>> +
>>> +#endif
>>> +
>>>  static int __init
>>>  setup_io_tlb_npages(char *str)
>>>  {
>>> @@ -449,6 +494,11 @@ phys_addr_t swiotlb_tbl_map_single(struct device 
>>> *hwdev,
>>> pr_warn_once("%s is active and system is using DMA bounce 
>>> buffers\n",
>>>  sme_active() ? "SME" : "SEV");
>>>  
>>> +#ifdef CONFIG_DEBUG_FS
>>> +   if (unlikely(!d_swiotlb_usage))
>>> +   

[PATCHv2 net 3/3] sctp: fa_resize sctp stream instead of redo fa_alloc

[Xin Long]

Now when doing 4-shakehand or adding new streams, sctp has to allocate
new memory for asoc->stream and copy the old stream's information from
the old asoc->stream to the new one. It also cause the stream pointers
to change, by which a panic was even caused due to stream->out_curr's
change.

To fix this, flex_array_resize() is used in sctp_stream_alloc_out/in()
when asoc->stream has been allocated. Besides, with this asoc->stream
will only be allocated once, and grow or shrink dynamically later.

Note that flex_array_prealloc() is needed before growing as fa_alloc
does, while flex_array_clear() and flex_array_shrink() are called to
free the unused memory before shrinking.

Fixes: 5e32a431 ("sctp: introduce stream scheduler foundations")
Reported-by: Ying Xu 
Reported-by: syzbot+e33a3a138267ca119...@syzkaller.appspotmail.com
Suggested-by: Neil Horman 
Signed-off-by: Xin Long 
Acked-by: Neil Horman 
---
 net/sctp/stream.c | 87 +--
 1 file changed, 40 insertions(+), 47 deletions(-)

diff --git a/net/sctp/stream.c b/net/sctp/stream.c
index 3892e76..aff30b2 100644
--- a/net/sctp/stream.c
+++ b/net/sctp/stream.c
@@ -37,6 +37,17 @@
 #include 
 #include 
 
+static void fa_zero(struct flex_array *fa, size_t index, size_t count)
+{
+   void *elem;
+
+   while (count--) {
+   elem = flex_array_get(fa, index);
+   memset(elem, 0, fa->element_size);
+   index++;
+   }
+}
+
 static struct flex_array *fa_alloc(size_t elem_size, size_t elem_count,
   gfp_t gfp)
 {
@@ -48,8 +59,9 @@ static struct flex_array *fa_alloc(size_t elem_size, size_t 
elem_count,
err = flex_array_prealloc(result, 0, elem_count, gfp);
if (err) {
flex_array_free(result);
-   result = NULL;
+   return NULL;
}
+   fa_zero(result, 0, elem_count);
}
 
return result;
@@ -61,27 +73,28 @@ static void fa_free(struct flex_array *fa)
flex_array_free(fa);
 }
 
-static void fa_copy(struct flex_array *fa, struct flex_array *from,
-   size_t index, size_t count)
+static int fa_resize(struct flex_array *fa, size_t count, gfp_t gfp)
 {
-   void *elem;
+   int nr = fa->total_nr_elements, n;
 
-   while (count--) {
-   elem = flex_array_get(from, index);
-   flex_array_put(fa, index, elem, 0);
-   index++;
+   if (count > nr) {
+   if (flex_array_resize(fa, count, gfp))
+   return -ENOMEM;
+   if (flex_array_prealloc(fa, nr, count - nr, gfp))
+   return -ENOMEM;
+   fa_zero(fa, nr, count - nr);
+
+   return 0;
}
-}
 
-static void fa_zero(struct flex_array *fa, size_t index, size_t count)
-{
-   void *elem;
+   /* Shrink the unused memory,
+* FLEX_ARRAY_FREE check is safe for sctp stream.
+*/
+   for (n = count; n < nr; n++)
+   flex_array_clear(fa, n);
+   flex_array_shrink(fa);
 
-   while (count--) {
-   elem = flex_array_get(fa, index);
-   memset(elem, 0, fa->element_size);
-   index++;
-   }
+   return flex_array_resize(fa, count, gfp);
 }
 
 /* Migrates chunks from stream queues to new stream queues if needed,
@@ -138,47 +151,27 @@ static void sctp_stream_outq_migrate(struct sctp_stream 
*stream,
 static int sctp_stream_alloc_out(struct sctp_stream *stream, __u16 outcnt,
 gfp_t gfp)
 {
-   struct flex_array *out;
-   size_t elem_size = sizeof(struct sctp_stream_out);
-
-   out = fa_alloc(elem_size, outcnt, gfp);
-   if (!out)
-   return -ENOMEM;
+   if (!stream->out) {
+   stream->out = fa_alloc(sizeof(struct sctp_stream_out),
+  outcnt, gfp);
 
-   if (stream->out) {
-   fa_copy(out, stream->out, 0, min(outcnt, stream->outcnt));
-   fa_free(stream->out);
+   return stream->out ? 0 : -ENOMEM;
}
 
-   if (outcnt > stream->outcnt)
-   fa_zero(out, stream->outcnt, (outcnt - stream->outcnt));
-
-   stream->out = out;
-
-   return 0;
+   return fa_resize(stream->out, outcnt, gfp);
 }
 
 static int sctp_stream_alloc_in(struct sctp_stream *stream, __u16 incnt,
gfp_t gfp)
 {
-   struct flex_array *in;
-   size_t elem_size = sizeof(struct sctp_stream_in);
+   if (!stream->in) {
+   stream->in = fa_alloc(sizeof(struct sctp_stream_in),
+ incnt, gfp);
 
-   in = fa_alloc(elem_size, incnt, gfp);
-   if (!in)
-   return -ENOMEM;
-
-   if (stream->in) {
-   fa_copy(in, stream->in, 0, min(incnt, stream->incnt));
-   

[PATCHv2 net 2/3] flex_array: support flex_array_resize

[Xin Long]

This function can dynamically change total_nr_elements of a flex_array,
and keep the old elements of the same memory. Returns 0 if it succeeds.

Note that it won't do any memory allocation or shrinking for elements,
which should be only done by flex_array_prealloc and flex_array_shrink.

Suggested-by: Neil Horman 
Signed-off-by: Xin Long 
Acked-by: Neil Horman 
---
 include/linux/flex_array.h | 11 +
 lib/flex_array.c   | 58 ++
 2 files changed, 69 insertions(+)

diff --git a/include/linux/flex_array.h b/include/linux/flex_array.h
index 29ad65f..19ff58d 100644
--- a/include/linux/flex_array.h
+++ b/include/linux/flex_array.h
@@ -130,6 +130,17 @@ void *flex_array_get(struct flex_array *fa, unsigned int 
element_nr);
  */
 int flex_array_shrink(struct flex_array *fa);
 
+/**
+ * flex_array_resize() - Resize without the old elements memory changed
+ * @fa:array to resize
+ * @total: total number of elements that this would change to
+ * @flags: page allocation flags to use for base array
+ *
+ * Return: Returns 0 if it succeeds.
+ *
+ */
+int flex_array_resize(struct flex_array *fa, unsigned int total, gfp_t flags);
+
 #define flex_array_put_ptr(fa, nr, src, gfp) \
flex_array_put(fa, nr, (void *)&(src), gfp)
 
diff --git a/lib/flex_array.c b/lib/flex_array.c
index 8c0b9b6..2f913e7 100644
--- a/lib/flex_array.c
+++ b/lib/flex_array.c
@@ -405,3 +405,61 @@ int flex_array_shrink(struct flex_array *fa)
return ret;
 }
 EXPORT_SYMBOL(flex_array_shrink);
+
+/**
+ * flex_array_resize - resize without the old elements memory changed
+ * @fa:the flex array to resize
+ * @total: total number of elements that this would change to
+ * @flags: page allocation flags to use for base array
+ *
+ * This function can dynamically change total_nr_elements of a flex_array,
+ * and keep the old elements of the same memory. Returns 0 if it succeeds.
+ * Note that it won't do any memory allocation or shrinking for elements,
+ * which should be only done by flex_array_prealloc and flex_array_shrink.
+ *
+ * Locking must be provided by the caller.
+ */
+int flex_array_resize(struct flex_array *fa, unsigned int total, gfp_t flags)
+{
+   int nr;
+
+   if (total > FLEX_ARRAY_NR_BASE_PTRS * fa->elems_per_part)
+   return -EINVAL;
+
+   if (elements_fit_in_base(fa)) {
+   struct flex_array_part_p *part_p;
+
+   nr = fa->total_nr_elements;
+   fa->total_nr_elements = total;
+   if (elements_fit_in_base(fa))
+   return 0;
+
+   part_p = kzalloc(sizeof(*part_p), flags);
+   if (!part_p) {
+   fa->total_nr_elements = nr;
+   return -ENOMEM;
+   }
+
+   part_p->p_part[0] = (struct flex_array_part *)>parts[0];
+   fa->part_p = part_p;
+   } else {
+   struct flex_array_part *part;
+
+   fa->total_nr_elements = total;
+   if (!elements_fit_in_base(fa))
+   return 0;
+
+   for (nr = 1; nr < FLEX_ARRAY_NR_BASE_PTRS; nr++) {
+   part = fa->parts[nr];
+   if (part) {
+   fa->parts[nr] = NULL;
+   kfree(part);
+   }
+   }
+
+   fa->part_p = (struct flex_array_part_p *)fa->parts[0];
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(flex_array_resize);
-- 
2.1.0

[PATCHv2 net 0/3] net: add support for flex_array_resize in flex_array

[Xin Long]

Without the support for the total_nr_elements's growing or shrinking
dynamically, flex_array is not that 'flexible'. Like when users want
to change the size, they have to redo flex_array_alloc and copy all
the elements from the old to the new one.  The worse thing is every
element's memory gets changed.

To implement flex_array_resize based on current code, the difficult
thing is to process the size border of FLEX_ARRAY_BASE_BYTES_LEFT,
where the base data memory may change to an array for the 2nd level
data memory for growing, likewise for shrinking.

To make this part easier, we separate the base data memory and define
FLEX_ARRAY_BASE_SIZE as a same value of FLEX_ARRAY_PART_SIZE, as Neil
suggested.  When new size is crossing the border, the base memory is
allocated as the array for the 2nd level data memory and its part[0]
is pointed to the old base memory, and do the opposite for shrinking.

But it doesn't do any memory allocation or shrinking for elements in
flex_array_resize, as which should be done by flex_array_prealloc or
flex_array_shrink called by users.  No memory leaks can be caused by
that.

SCTP has benefited a lot from flex_array_resize() for managing its
stream memory so far.

v1->v2:
  Cc LKML and more developers.

Xin Long (3):
  flex_array: make FLEX_ARRAY_BASE_SIZE the same value of
FLEX_ARRAY_PART_SIZE
  flex_array: support flex_array_resize
  sctp: fa_resize sctp stream instead of redo fa_alloc

 include/linux/flex_array.h | 40 ++---
 lib/flex_array.c   | 73 --
 net/sctp/stream.c  | 87 +-
 3 files changed, 130 insertions(+), 70 deletions(-)

-- 
2.1.0

[PATCHv2 net 1/3] flex_array: make FLEX_ARRAY_BASE_SIZE the same value of FLEX_ARRAY_PART_SIZE

[Xin Long]

This patch is to separate the base data memory from struct flex_array and
save it into a page. With this change, total_nr_elements of a flex_array
can grow or shrink without having the old element's memory changed when
the new size of the flex_arry crosses FLEX_ARRAY_BASE_SIZE, which will
be added in the next patch.

Suggested-by: Neil Horman 
Signed-off-by: Xin Long 
Acked-by: Neil Horman 
---
 include/linux/flex_array.h | 29 +
 lib/flex_array.c   | 15 ---
 2 files changed, 21 insertions(+), 23 deletions(-)

diff --git a/include/linux/flex_array.h b/include/linux/flex_array.h
index b94fa61..29ad65f 100644
--- a/include/linux/flex_array.h
+++ b/include/linux/flex_array.h
@@ -7,9 +7,10 @@
 #include 
 
 #define FLEX_ARRAY_PART_SIZE PAGE_SIZE
-#define FLEX_ARRAY_BASE_SIZE PAGE_SIZE
+#define FLEX_ARRAY_BASE_SIZE FLEX_ARRAY_PART_SIZE
 
 struct flex_array_part;
+struct flex_array_part_p;
 
 /*
  * This is meant to replace cases where an array-like
@@ -19,29 +20,17 @@ struct flex_array_part;
  */
 
 struct flex_array {
-   union {
-   struct {
-   int element_size;
-   int total_nr_elements;
-   int elems_per_part;
-   struct reciprocal_value reciprocal_elems;
-   struct flex_array_part *parts[];
-   };
-   /*
-* This little trick makes sure that
-* sizeof(flex_array) == PAGE_SIZE
-*/
-   char padding[FLEX_ARRAY_BASE_SIZE];
-   };
+   int element_size;
+   int total_nr_elements;
+   int elems_per_part;
+   struct reciprocal_value reciprocal_elems;
+   struct flex_array_part_p *part_p;
+#define parts part_p->p_part
 };
 
-/* Number of bytes left in base struct flex_array, excluding metadata */
-#define FLEX_ARRAY_BASE_BYTES_LEFT \
-   (FLEX_ARRAY_BASE_SIZE - offsetof(struct flex_array, parts))
-
 /* Number of pointers in base to struct flex_array_part pages */
 #define FLEX_ARRAY_NR_BASE_PTRS
\
-   (FLEX_ARRAY_BASE_BYTES_LEFT / sizeof(struct flex_array_part *))
+   (FLEX_ARRAY_BASE_SIZE / sizeof(struct flex_array_part *))
 
 /* Number of elements of size that fit in struct flex_array_part */
 #define FLEX_ARRAY_ELEMENTS_PER_PART(size) \
diff --git a/lib/flex_array.c b/lib/flex_array.c
index 2eed22f..8c0b9b6 100644
--- a/lib/flex_array.c
+++ b/lib/flex_array.c
@@ -30,6 +30,10 @@ struct flex_array_part {
char elements[FLEX_ARRAY_PART_SIZE];
 };
 
+struct flex_array_part_p {
+   struct flex_array_part *p_part[FLEX_ARRAY_NR_BASE_PTRS];
+};
+
 /*
  * If a user requests an allocation which is small
  * enough, we may simply use the space in the
@@ -39,7 +43,7 @@ struct flex_array_part {
 static inline int elements_fit_in_base(struct flex_array *fa)
 {
int data_size = fa->element_size * fa->total_nr_elements;
-   if (data_size <= FLEX_ARRAY_BASE_BYTES_LEFT)
+   if (data_size <= FLEX_ARRAY_BASE_SIZE)
return 1;
return 0;
 }
@@ -105,13 +109,17 @@ struct flex_array *flex_array_alloc(int element_size, 
unsigned int total,
ret = kzalloc(sizeof(struct flex_array), flags);
if (!ret)
return NULL;
+   ret->part_p = kzalloc(sizeof(struct flex_array_part_p), flags);
+   if (!ret->part_p) {
+   kfree(ret);
+   return NULL;
+   }
ret->element_size = element_size;
ret->total_nr_elements = total;
ret->elems_per_part = elems_per_part;
ret->reciprocal_elems = reciprocal_elems;
if (elements_fit_in_base(ret) && !(flags & __GFP_ZERO))
-   memset(>parts[0], FLEX_ARRAY_FREE,
-   FLEX_ARRAY_BASE_BYTES_LEFT);
+   memset(>parts[0], FLEX_ARRAY_FREE, FLEX_ARRAY_BASE_SIZE);
return ret;
 }
 EXPORT_SYMBOL(flex_array_alloc);
@@ -148,6 +156,7 @@ EXPORT_SYMBOL(flex_array_free_parts);
 void flex_array_free(struct flex_array *fa)
 {
flex_array_free_parts(fa);
+   kfree(fa->part_p);
kfree(fa);
 }
 EXPORT_SYMBOL(flex_array_free);
-- 
2.1.0

Re: [PATCH net-next v2 0/4] net: mitigate retpoline overhead

[David Miller]

From: David Miller 
Date: Thu, 06 Dec 2018 22:24:09 -0800 (PST)

> Series applied, thanks!

Erm... actually reverted.  Please fix these build failures:

ld: net/ipv6/ip6_offload.o: in function `ipv6_gro_receive':
ip6_offload.c:(.text+0xda2): undefined reference to `udp6_gro_receive'
ld: ip6_offload.c:(.text+0xdb6): undefined reference to `udp6_gro_receive'
ld: net/ipv6/ip6_offload.o: in function `ipv6_gro_complete':
ip6_offload.c:(.text+0x1953): undefined reference to `udp6_gro_complete'
ld: ip6_offload.c:(.text+0x1966): undefined reference to `udp6_gro_complete'
make: *** [Makefile:1036: vmlinux] Error 1

THanks.

Re: [PATCH v1 0/4] phy: qcom-qmp: Fix clock-cells binding and provider

[Vivek Gautam]

Hi,

On Fri, Dec 7, 2018 at 10:15 AM Kishon Vijay Abraham I  wrote:
>
> Vivek,
>
> On 04/12/18 6:07 PM, Vivek Gautam wrote:
> > Hi Kishon,
> >
> > On Tue, Dec 4, 2018 at 1:44 PM Kishon Vijay Abraham I  wrote:
> >>
> >> Hi Andy Gross, David Brown, Vivek,
> >>
> >> On 30/11/18 3:43 AM, Evan Green wrote:
> >>> This series fixes the QMP PHY bindings, which had specified #clock-cells
> >>> in the parent node, and had set it to 1. Putting it in the parent node is
> >>> wrong because the clock providers are the child nodes, so this change
> >>> moves it there. Having it set to 1 is also wrong, since nothing is ever
> >>> specified as to what should go in that cell. So this changes it to zero.
> >>> Finally, this change completes a little bit of code to actually allow 
> >>> these
> >>> exposed clocks to be pointed at in DT.
> >>>
> >>> I had no idea how to fix up ipq8074.dtsi. It seems to be completely wrong 
> >>> in
> >>> that it doesn't specify #clock-cells at all, has no child nodes, and
> >>> specifies clock-output-names in the parent node. As far as I can tell this
> >>> doesn't work at all. But I can't add the child nodes myself because I 
> >>> don't know
> >>> 1) how many there are, and 2) the registers in them. I also have no way 
> >>> to test it.
> >>>
> >>> Speaking of testing, I was able to test this on sdm845, but haven't 
> >>> tested msm8996.
> >>
> >> Can someone help test this series in msm8996?
> >
> > Sure, will give it a try tomorrow.
>
> I'm planning to close the merge by today. Can you test this series please?

Sorry, got held up with an issue yesterday. Will update you in couple of hours.

Thanks
Vivek

[snip]


-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH v1 0/4] phy: qcom-qmp: Fix clock-cells binding and provider

[Vivek Gautam]

Hi,

On Fri, Dec 7, 2018 at 10:15 AM Kishon Vijay Abraham I  wrote:
>
> Vivek,
>
> On 04/12/18 6:07 PM, Vivek Gautam wrote:
> > Hi Kishon,
> >
> > On Tue, Dec 4, 2018 at 1:44 PM Kishon Vijay Abraham I  wrote:
> >>
> >> Hi Andy Gross, David Brown, Vivek,
> >>
> >> On 30/11/18 3:43 AM, Evan Green wrote:
> >>> This series fixes the QMP PHY bindings, which had specified #clock-cells
> >>> in the parent node, and had set it to 1. Putting it in the parent node is
> >>> wrong because the clock providers are the child nodes, so this change
> >>> moves it there. Having it set to 1 is also wrong, since nothing is ever
> >>> specified as to what should go in that cell. So this changes it to zero.
> >>> Finally, this change completes a little bit of code to actually allow 
> >>> these
> >>> exposed clocks to be pointed at in DT.
> >>>
> >>> I had no idea how to fix up ipq8074.dtsi. It seems to be completely wrong 
> >>> in
> >>> that it doesn't specify #clock-cells at all, has no child nodes, and
> >>> specifies clock-output-names in the parent node. As far as I can tell this
> >>> doesn't work at all. But I can't add the child nodes myself because I 
> >>> don't know
> >>> 1) how many there are, and 2) the registers in them. I also have no way 
> >>> to test it.
> >>>
> >>> Speaking of testing, I was able to test this on sdm845, but haven't 
> >>> tested msm8996.
> >>
> >> Can someone help test this series in msm8996?
> >
> > Sure, will give it a try tomorrow.
>
> I'm planning to close the merge by today. Can you test this series please?

Sorry, got held up with an issue yesterday. Will update you in couple of hours.

Thanks
Vivek

[snip]


-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH net-next v2 0/4] net: mitigate retpoline overhead

[David Miller]

From: Paolo Abeni 
Date: Wed,  5 Dec 2018 19:13:38 +0100

> The spectre v2 counter-measures, aka retpolines, are a source of measurable
> overhead[1]. We can partially address that when the function pointer refers to
> a builtin symbol resorting to a list of tests vs well-known builtin function 
> and
> direct calls.
> 
> Experimental results show that replacing a single indirect call via
> retpoline with several branches and a direct call gives performance gains
> even when multiple branches are added - 5 or more, as reported in [2].
> 
> This may lead to some uglification around the indirect calls. In netconf 2018
> Eric Dumazet described a technique to hide the most relevant part of the 
> needed
> boilerplate with some macro help.
> 
> This series is a [re-]implementation of such idea, exposing the introduced
> helpers in a new header file. They are later leveraged to avoid the indirect
> call overhead in the GRO path, when possible.
> 
> Overall this gives > 10% performance improvement for UDP GRO benchmark and
> smaller but measurable for TCP syn flood.
> 
> The added infra can be used in follow-up patches to cope with retpoline 
> overhead
> in other points of the networking stack (e.g. at the qdisc layer) and possibly
> even in other subsystems.
 ...

Series applied, thanks!

Re: [PATCH -V8 00/21] swap: Swapout/swapin THP in one piece

[Huang, Ying]

Huang Ying  writes:

> Hi, Andrew, could you help me to check whether the overall design is
> reasonable?
>
> Hi, Hugh, Shaohua, Minchan and Rik, could you help me to review the
> swap part of the patchset?  Especially [02/21], [03/21], [04/21],
> [05/21], [06/21], [07/21], [08/21], [09/21], [10/21], [11/21],
> [12/21], [20/21], [21/21].
>
> Hi, Andrea and Kirill, could you help me to review the THP part of the
> patchset?  Especially [01/21], [07/21], [09/21], [11/21], [13/21],
> [15/21], [16/21], [17/21], [18/21], [19/21], [20/21].
>
> Hi, Johannes and Michal, could you help me to review the cgroup part
> of the patchset?  Especially [14/21].
>
> And for all, Any comment is welcome!
>
> This patchset is based on the 2018-11-29 head of mmotm/master.

Sorry, just after sending this patchset out, I found there is a new
version of mmotm/master (2018-12-04), and the swapoff() implementation
is changed much.  I will rebase this patchset on the new version,
especially the swapoff() support.

So, please ignore this patchset, I will send out a new version soon.
Sorry again for bothering.

Best Regards,
Huang, Ying

Re: [PATCH -V8 00/21] swap: Swapout/swapin THP in one piece

[Huang, Ying]

Huang Ying  writes:

> Hi, Andrew, could you help me to check whether the overall design is
> reasonable?
>
> Hi, Hugh, Shaohua, Minchan and Rik, could you help me to review the
> swap part of the patchset?  Especially [02/21], [03/21], [04/21],
> [05/21], [06/21], [07/21], [08/21], [09/21], [10/21], [11/21],
> [12/21], [20/21], [21/21].
>
> Hi, Andrea and Kirill, could you help me to review the THP part of the
> patchset?  Especially [01/21], [07/21], [09/21], [11/21], [13/21],
> [15/21], [16/21], [17/21], [18/21], [19/21], [20/21].
>
> Hi, Johannes and Michal, could you help me to review the cgroup part
> of the patchset?  Especially [14/21].
>
> And for all, Any comment is welcome!
>
> This patchset is based on the 2018-11-29 head of mmotm/master.

Sorry, just after sending this patchset out, I found there is a new
version of mmotm/master (2018-12-04), and the swapoff() implementation
is changed much.  I will rebase this patchset on the new version,
especially the swapoff() support.

So, please ignore this patchset, I will send out a new version soon.
Sorry again for bothering.

Best Regards,
Huang, Ying

Re: [PATCH v5 00/11] crypto: crypto_user_stat: misc enhancement

[Herbert Xu]

On Thu, Nov 29, 2018 at 02:42:15PM +, Corentin Labbe wrote:
> Hello
> 
> This patchset fixes all reported problem by Eric biggers.
> 
> Regards
> 
> Changes since v4:
> - Inlined functions when !CRYPTO_STATS
> 
> Changes since v3:
> - Added a crypto_stats_init as asked vy Neil Horman
> - Fixed some checkpatch complaints
> 
> Changes since v2:
> - moved all crypto_stats functions from header to algapi.c for using
>   crypto_alg_get/put
> 
> Changes since v1:
> - Better locking of crypto_alg via crypto_alg_get/crypto_alg_put
> - remove all intermediate variables in crypto/crypto_user_stat.c
> - splited all internal stats variables into different structures
> 
> Corentin Labbe (11):
>   crypto: crypto_user_stat: made crypto_user_stat optional
>   crypto: CRYPTO_STATS should depend on CRYPTO_USER
>   crypto: crypto_user_stat: convert all stats from u32 to u64
>   crypto: crypto_user_stat: split user space crypto stat structures
>   crypto: tool: getstat: convert user space example to the new
> crypto_user_stat uapi
>   crypto: crypto_user_stat: fix use_after_free of struct xxx_request
>   crypto: crypto_user_stat: Fix invalid stat reporting
>   crypto: crypto_user_stat: remove intermediate variable
>   crypto: crypto_user_stat: Split stats in multiple structures
>   crypto: crypto_user_stat: rename err_cnt parameter
>   crypto: crypto_user_stat: Add crypto_stats_init
> 
>  crypto/Kconfig   |   1 +
>  crypto/Makefile  |   3 +-
>  crypto/ahash.c   |  17 +-
>  crypto/algapi.c  | 247 ++-
>  crypto/crypto_user_stat.c| 160 +--
>  crypto/rng.c |   4 +-
>  include/crypto/acompress.h   |  38 +---
>  include/crypto/aead.h|  38 +---
>  include/crypto/akcipher.h|  74 ++-
>  include/crypto/hash.h|  32 +--
>  include/crypto/internal/cryptouser.h |  17 ++
>  include/crypto/kpp.h |  48 +
>  include/crypto/rng.h |  27 +--
>  include/crypto/skcipher.h|  36 +---
>  include/linux/crypto.h   | 290 ++-
>  include/uapi/linux/cryptouser.h  | 102 ++
>  tools/crypto/getstat.c   |  72 +++
>  17 files changed, 676 insertions(+), 530 deletions(-)

All applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: cavium/nitrox convert to DEFINE_SHOW_ATTRIBUTE

[Herbert Xu]

On Sat, Dec 01, 2018 at 04:56:30AM -0500, Yangtao Li wrote:
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
> 
> Signed-off-by: Yangtao Li 
> ---
>  drivers/crypto/cavium/nitrox/nitrox_debugfs.c | 48 ---
>  1 file changed, 9 insertions(+), 39 deletions(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] MAINTAINERS: change NX/VMX maintainers

[Herbert Xu]

On Tue, Nov 27, 2018 at 03:27:21PM -0200, Paulo Flabiano Smorigo wrote:
> Add Breno and Nayna as NX/VMX crypto driver maintainers. Also change my
> email address to my personal account and remove Leonidas since he's not
> working with the driver anymore.
> 
> Signed-off-by: Paulo Flabiano Smorigo 
> ---
>  MAINTAINERS | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 0/3] new HW version and co-maintainer

[Herbert Xu]

On Tue, Nov 13, 2018 at 09:40:34AM +, Gilad Ben-Yossef wrote:
> Add support for CryptoCell 703 HW revision and a new co-maintainer.
> 
> Gilad Ben-Yossef (3):
>   crypto: ccree: add support for CryptoCell 703
>   dt-bindings: crypto: ccree: add dt bindings for ccree 703
>   MAINTAINERS: ccree: add co-maintainer
> 
>  .../devicetree/bindings/crypto/arm-cryptocell.txt  |  1 +
>  MAINTAINERS|  1 +
>  drivers/crypto/Kconfig |  2 +-
>  drivers/crypto/ccree/cc_aead.c | 16 -
>  drivers/crypto/ccree/cc_cipher.c   | 38 
> +-
>  drivers/crypto/ccree/cc_driver.c   | 19 ---
>  drivers/crypto/ccree/cc_driver.h   |  8 +
>  drivers/crypto/ccree/cc_hash.c | 16 +++--
>  8 files changed, 92 insertions(+), 9 deletions(-)

All applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH v5 1/3] mm: Add support for kmem caches in DMA32 zone

[Nicolas Boichat]

IOMMUs using ARMv7 short-descriptor format require page tables
to be allocated within the first 4GB of RAM, even on 64-bit systems.
On arm64, this is done by passing GFP_DMA32 flag to memory allocation
functions.

For IOMMU L2 tables that only take 1KB, it would be a waste to allocate
a full page using get_free_pages, so we considered 3 approaches:
 1. This patch, adding support for GFP_DMA32 slab caches.
 2. genalloc, which requires pre-allocating the maximum number of L2
page tables (4096, so 4MB of memory).
 3. page_frag, which is not very memory-efficient as it is unable
to reuse freed fragments until the whole page is freed.

This change makes it possible to create a custom cache in DMA32 zone
using kmem_cache_create, then allocate memory using kmem_cache_alloc.

We do not create a DMA32 kmalloc cache array, as there are currently
no users of kmalloc(..., GFP_DMA32). These calls will continue to
trigger a warning, as we keep GFP_DMA32 in GFP_SLAB_BUG_MASK.

This implies that calls to kmem_cache_*alloc on a SLAB_CACHE_DMA32
kmem_cache must _not_ use GFP_DMA32 (it is anyway redundant and
unnecessary).

Signed-off-by: Nicolas Boichat 
---

Changes since v2:
 - Clarified commit message
 - Add entry in sysfs-kernel-slab to document the new sysfs file

(v3 used the page_frag approach)

Changes since v4:
 - Added details to commit message
 - Dropped change that removed GFP_DMA32 from GFP_SLAB_BUG_MASK:
   instead we can just call kmem_cache_*alloc without GFP_DMA32
   parameter. This also means that we can drop PATCH 1/3, as we
   do not make any changes in GFP flag verification.
 - Dropped hunks that added cache_dma32 sysfs file, and moved
   the hunks to PATCH 3/3, so that maintainer can decide whether
   to pick the change independently.

 include/linux/slab.h | 2 ++
 mm/slab.c| 2 ++
 mm/slab.h| 3 ++-
 mm/slab_common.c | 2 +-
 mm/slub.c| 5 +
 5 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/include/linux/slab.h b/include/linux/slab.h
index 11b45f7ae4057c..9449b19c5f107a 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -32,6 +32,8 @@
 #define SLAB_HWCACHE_ALIGN ((slab_flags_t __force)0x2000U)
 /* Use GFP_DMA memory */
 #define SLAB_CACHE_DMA ((slab_flags_t __force)0x4000U)
+/* Use GFP_DMA32 memory */
+#define SLAB_CACHE_DMA32   ((slab_flags_t __force)0x8000U)
 /* DEBUG: Store the last owner for bug hunting */
 #define SLAB_STORE_USER((slab_flags_t __force)0x0001U)
 /* Panic if kmem_cache_create() fails */
diff --git a/mm/slab.c b/mm/slab.c
index 73fe23e649c91a..124f8c556d27fb 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2109,6 +2109,8 @@ int __kmem_cache_create(struct kmem_cache *cachep, 
slab_flags_t flags)
cachep->allocflags = __GFP_COMP;
if (flags & SLAB_CACHE_DMA)
cachep->allocflags |= GFP_DMA;
+   if (flags & SLAB_CACHE_DMA32)
+   cachep->allocflags |= GFP_DMA32;
if (flags & SLAB_RECLAIM_ACCOUNT)
cachep->allocflags |= __GFP_RECLAIMABLE;
cachep->size = size;
diff --git a/mm/slab.h b/mm/slab.h
index 4190c24ef0e9df..fcf717e12f0a86 100644
--- a/mm/slab.h
+++ b/mm/slab.h
@@ -127,7 +127,8 @@ static inline slab_flags_t kmem_cache_flags(unsigned int 
object_size,
 
 
 /* Legal flag mask for kmem_cache_create(), for various configurations */
-#define SLAB_CORE_FLAGS (SLAB_HWCACHE_ALIGN | SLAB_CACHE_DMA | SLAB_PANIC | \
+#define SLAB_CORE_FLAGS (SLAB_HWCACHE_ALIGN | SLAB_CACHE_DMA | \
+SLAB_CACHE_DMA32 | SLAB_PANIC | \
 SLAB_TYPESAFE_BY_RCU | SLAB_DEBUG_OBJECTS )
 
 #if defined(CONFIG_DEBUG_SLAB)
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 70b0cc85db67f8..18b7b809c8d064 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -53,7 +53,7 @@ static DECLARE_WORK(slab_caches_to_rcu_destroy_work,
SLAB_FAILSLAB | SLAB_KASAN)
 
 #define SLAB_MERGE_SAME (SLAB_RECLAIM_ACCOUNT | SLAB_CACHE_DMA | \
-SLAB_ACCOUNT)
+SLAB_CACHE_DMA32 | SLAB_ACCOUNT)
 
 /*
  * Merge control. If this is set then no merging of slab caches will occur.
diff --git a/mm/slub.c b/mm/slub.c
index c229a9b7dd5448..4caadb926838ef 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3583,6 +3583,9 @@ static int calculate_sizes(struct kmem_cache *s, int 
forced_order)
if (s->flags & SLAB_CACHE_DMA)
s->allocflags |= GFP_DMA;
 
+   if (s->flags & SLAB_CACHE_DMA32)
+   s->allocflags |= GFP_DMA32;
+
if (s->flags & SLAB_RECLAIM_ACCOUNT)
s->allocflags |= __GFP_RECLAIMABLE;
 
@@ -5671,6 +5674,8 @@ static char *create_unique_id(struct kmem_cache *s)
 */
if (s->flags & SLAB_CACHE_DMA)
*p++ = 'd';
+   if (s->flags & SLAB_CACHE_DMA32)
+   *p++ = 'D';
if (s->flags & SLAB_RECLAIM_ACCOUNT)
*p++ = 'a';
if 

[PATCH v5 0/3] iommu/io-pgtable-arm-v7s: Use DMA32 zone for page tables

[Nicolas Boichat]

This is a follow-up to the discussion in [1], [2].

IOMMUs using ARMv7 short-descriptor format require page tables
(level 1 and 2) to be allocated within the first 4GB of RAM, even
on 64-bit systems.

For L1 tables that are bigger than a page, we can just use __get_free_pages
with GFP_DMA32 (on arm64 systems only, arm would still use GFP_DMA).

For L2 tables that only take 1KB, it would be a waste to allocate a full
page, so we considered 3 approaches:
 1. This series, adding support for GFP_DMA32 slab caches.
 2. genalloc, which requires pre-allocating the maximum number of L2 page
tables (4096, so 4MB of memory).
 3. page_frag, which is not very memory-efficient as it is unable to reuse
freed fragments until the whole page is freed. [3]

This series is the most memory-efficient approach.

[1] https://lists.linuxfoundation.org/pipermail/iommu/2018-November/030876.html
[2] https://lists.linuxfoundation.org/pipermail/iommu/2018-December/031696.html
[3] https://patchwork.codeaurora.org/patch/671639/

Changes since v1:
 - Add support for SLAB_CACHE_DMA32 in slab and slub (patches 1/2)
 - iommu/io-pgtable-arm-v7s (patch 3):
   - Changed approach to use SLAB_CACHE_DMA32 added by the previous
 commit.
   - Use DMA or DMA32 depending on the architecture (DMA for arm,
 DMA32 for arm64).

Changes since v2:
 - Reworded and expanded commit messages
 - Added cache_dma32 documentation in PATCH 2/3.

v3 used the page_frag approach, see [3].

Changes since v4:
 - Dropped change that removed GFP_DMA32 from GFP_SLAB_BUG_MASK:
   instead we can just call kmem_cache_*alloc without GFP_DMA32
   parameter. This also means that we can drop PATCH v4 1/3, as we
   do not make any changes in GFP flag verification.
 - Dropped hunks that added cache_dma32 sysfs file, and moved
   the hunks to PATCH v5 3/3, so that maintainer can decide whether
   to pick the change independently.

Nicolas Boichat (3):
  mm: Add support for kmem caches in DMA32 zone
  iommu/io-pgtable-arm-v7s: Request DMA32 memory, and improve debugging
  mm: Add /sys/kernel/slab/cache/cache_dma32

 Documentation/ABI/testing/sysfs-kernel-slab |  9 +
 drivers/iommu/io-pgtable-arm-v7s.c  | 19 +++
 include/linux/slab.h|  2 ++
 mm/slab.c   |  2 ++
 mm/slab.h   |  3 ++-
 mm/slab_common.c|  2 +-
 mm/slub.c   | 16 
 tools/vm/slabinfo.c |  7 ++-
 8 files changed, 53 insertions(+), 7 deletions(-)

-- 
2.20.0.rc2.403.gdbc3b29805-goog

Re: [PATCH v4 0/5] powerpc: system call table generation support

[Firoz Khan]

++ sathn...@linux.vnet.ibm.com,

Hi Satheesh,

On Fri, 7 Dec 2018 at 11:42, Firoz Khan  wrote:
>
>
> Changes since v3:
>  - split compat syscall table out from native table.
>  - modified the script to add new line in the generated
>file.

I have fixed few major issue. Could you perform boot test with v4
on the platform.

Thanks
Firoz

[PATCH v5 3/3] mm: Add /sys/kernel/slab/cache/cache_dma32

[Nicolas Boichat]

A previous patch in this series adds support for SLAB_CACHE_DMA32
kmem caches. This adds the corresponding
/sys/kernel/slab/cache/cache_dma32 entries, and fixes slabinfo
tool.

Signed-off-by: Nicolas Boichat 
---

There were different opinions on whether this sysfs entry should
be added, so I'll leave it up to the mm/slub maintainers to decide
whether they want to pick this up, or drop it.

 Documentation/ABI/testing/sysfs-kernel-slab |  9 +
 mm/slub.c   | 11 +++
 tools/vm/slabinfo.c |  7 ++-
 3 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/Documentation/ABI/testing/sysfs-kernel-slab 
b/Documentation/ABI/testing/sysfs-kernel-slab
index 29601d93a1c2ea..d742c6cfdffbe9 100644
--- a/Documentation/ABI/testing/sysfs-kernel-slab
+++ b/Documentation/ABI/testing/sysfs-kernel-slab
@@ -106,6 +106,15 @@ Description:
are from ZONE_DMA.
Available when CONFIG_ZONE_DMA is enabled.
 
+What:  /sys/kernel/slab/cache/cache_dma32
+Date:  December 2018
+KernelVersion: 4.21
+Contact:   Nicolas Boichat 
+Description:
+   The cache_dma32 file is read-only and specifies whether objects
+   are from ZONE_DMA32.
+   Available when CONFIG_ZONE_DMA32 is enabled.
+
 What:  /sys/kernel/slab/cache/cpu_slabs
 Date:  May 2007
 KernelVersion: 2.6.22
diff --git a/mm/slub.c b/mm/slub.c
index 4caadb926838ef..840f3719d9d543 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -5104,6 +5104,14 @@ static ssize_t cache_dma_show(struct kmem_cache *s, char 
*buf)
 SLAB_ATTR_RO(cache_dma);
 #endif
 
+#ifdef CONFIG_ZONE_DMA32
+static ssize_t cache_dma32_show(struct kmem_cache *s, char *buf)
+{
+   return sprintf(buf, "%d\n", !!(s->flags & SLAB_CACHE_DMA32));
+}
+SLAB_ATTR_RO(cache_dma32);
+#endif
+
 static ssize_t usersize_show(struct kmem_cache *s, char *buf)
 {
return sprintf(buf, "%u\n", s->usersize);
@@ -5444,6 +5452,9 @@ static struct attribute *slab_attrs[] = {
 #ifdef CONFIG_ZONE_DMA
_dma_attr.attr,
 #endif
+#ifdef CONFIG_ZONE_DMA32
+   _dma32_attr.attr,
+#endif
 #ifdef CONFIG_NUMA
_node_defrag_ratio_attr.attr,
 #endif
diff --git a/tools/vm/slabinfo.c b/tools/vm/slabinfo.c
index 334b16db0ebbe9..4ee1bf6e498dfa 100644
--- a/tools/vm/slabinfo.c
+++ b/tools/vm/slabinfo.c
@@ -29,7 +29,7 @@ struct slabinfo {
char *name;
int alias;
int refs;
-   int aliases, align, cache_dma, cpu_slabs, destroy_by_rcu;
+   int aliases, align, cache_dma, cache_dma32, cpu_slabs, destroy_by_rcu;
unsigned int hwcache_align, object_size, objs_per_slab;
unsigned int sanity_checks, slab_size, store_user, trace;
int order, poison, reclaim_account, red_zone;
@@ -531,6 +531,8 @@ static void report(struct slabinfo *s)
printf("** Hardware cacheline aligned\n");
if (s->cache_dma)
printf("** Memory is allocated in a special DMA zone\n");
+   if (s->cache_dma32)
+   printf("** Memory is allocated in a special DMA32 zone\n");
if (s->destroy_by_rcu)
printf("** Slabs are destroyed via RCU\n");
if (s->reclaim_account)
@@ -599,6 +601,8 @@ static void slabcache(struct slabinfo *s)
*p++ = '*';
if (s->cache_dma)
*p++ = 'd';
+   if (s->cache_dma32)
+   *p++ = 'D';
if (s->hwcache_align)
*p++ = 'A';
if (s->poison)
@@ -1205,6 +1209,7 @@ static void read_slab_dir(void)
slab->aliases = get_obj("aliases");
slab->align = get_obj("align");
slab->cache_dma = get_obj("cache_dma");
+   slab->cache_dma32 = get_obj("cache_dma32");
slab->cpu_slabs = get_obj("cpu_slabs");
slab->destroy_by_rcu = get_obj("destroy_by_rcu");
slab->hwcache_align = get_obj("hwcache_align");
-- 
2.20.0.rc2.403.gdbc3b29805-goog

[PATCH v5 2/3] iommu/io-pgtable-arm-v7s: Request DMA32 memory, and improve debugging

[Nicolas Boichat]

IOMMUs using ARMv7 short-descriptor format require page tables
(level 1 and 2) to be allocated within the first 4GB of RAM, even
on 64-bit systems.

For level 1/2 pages, ensure GFP_DMA32 is used if CONFIG_ZONE_DMA32
is defined (e.g. on arm64 platforms).

For level 2 pages, allocate a slab cache in SLAB_CACHE_DMA32. Note
that we do not explicitly pass GFP_DMA[32] to kmem_cache_zalloc,
as this is not strictly necessary, and would cause a warning
in mm/sl*b.c, as we did not update GFP_SLAB_BUG_MASK.

Also, print an error when the physical address does not fit in
32-bit, to make debugging easier in the future.

Fixes: ad67f5a6545f ("arm64: replace ZONE_DMA with ZONE_DMA32")
Signed-off-by: Nicolas Boichat 
---

Changes since v2:
 - Commit message

(v3 used the page_frag approach)

Changes since v4:
 - Do not pass ARM_V7S_TABLE_GFP_DMA to kmem_cache_zalloc, as this
   is unnecessary, and would trigger a warning.

 drivers/iommu/io-pgtable-arm-v7s.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/io-pgtable-arm-v7s.c 
b/drivers/iommu/io-pgtable-arm-v7s.c
index 445c3bde04800c..f311fe1dfa47b7 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -161,6 +161,14 @@
 
 #define ARM_V7S_TCR_PD1BIT(5)
 
+#ifdef CONFIG_ZONE_DMA32
+#define ARM_V7S_TABLE_GFP_DMA GFP_DMA32
+#define ARM_V7S_TABLE_SLAB_CACHE SLAB_CACHE_DMA32
+#else
+#define ARM_V7S_TABLE_GFP_DMA GFP_DMA
+#define ARM_V7S_TABLE_SLAB_CACHE SLAB_CACHE_DMA
+#endif
+
 typedef u32 arm_v7s_iopte;
 
 static bool selftest_running;
@@ -198,13 +206,16 @@ static void *__arm_v7s_alloc_table(int lvl, gfp_t gfp,
void *table = NULL;
 
if (lvl == 1)
-   table = (void *)__get_dma_pages(__GFP_ZERO, get_order(size));
+   table = (void *)__get_free_pages(
+   __GFP_ZERO | ARM_V7S_TABLE_GFP_DMA, get_order(size));
else if (lvl == 2)
-   table = kmem_cache_zalloc(data->l2_tables, gfp | GFP_DMA);
+   table = kmem_cache_zalloc(data->l2_tables, gfp);
phys = virt_to_phys(table);
-   if (phys != (arm_v7s_iopte)phys)
+   if (phys != (arm_v7s_iopte)phys) {
/* Doesn't fit in PTE */
+   dev_err(dev, "Page table does not fit in PTE: %pa", );
goto out_free;
+   }
if (table && !(cfg->quirks & IO_PGTABLE_QUIRK_NO_DMA)) {
dma = dma_map_single(dev, table, size, DMA_TO_DEVICE);
if (dma_mapping_error(dev, dma))
@@ -737,7 +748,7 @@ static struct io_pgtable *arm_v7s_alloc_pgtable(struct 
io_pgtable_cfg *cfg,
data->l2_tables = kmem_cache_create("io-pgtable_armv7s_l2",
ARM_V7S_TABLE_SIZE(2),
ARM_V7S_TABLE_SIZE(2),
-   SLAB_CACHE_DMA, NULL);
+   ARM_V7S_TABLE_SLAB_CACHE, NULL);
if (!data->l2_tables)
goto out_free_data;
 
-- 
2.20.0.rc2.403.gdbc3b29805-goog

Re: [PATCH] mm, kmemleak: Little optimization while scanning

[Oscar Salvador]

> > +
> 
> This one maybe not necessary.

Yeah, that is a remind of an include file I used for time measurement.
I hope Andrew can drop that if this is taken.

> > /*
> >  * Kmemleak configuration and common defines.
> >  */
> > @@ -1547,11 +1548,14 @@ static void kmemleak_scan(void)
> > unsigned long pfn;
> > 
> > for (pfn = start_pfn; pfn < end_pfn; pfn++) {
> > -   struct page *page;
> > +   struct page *page =
> > pfn_to_online_page(pfn);
> > +
> > +   if (!page)
> > +   continue;
> > 
> > -   if (!pfn_valid(pfn))
> > +   /* only scan pages belonging to this node
> > */
> > +   if (page_to_nid(page) != i)
> > continue;
> 
> Not farmiliar with this situation. Is this often?
Well, hard to tell how often that happens because that mostly depends
on the Hardware in case of baremetal.
Virtual systems can also have it though.

> 
> > -   page = pfn_to_page(pfn);
> > /* only scan if page is in use */
> > if (page_count(page) == 0)
> > continue;
> > -- 
> > 2.13.7
> 
> 
-- 
Oscar Salvador
SUSE L3

Re: [PATCH] mm, kmemleak: Little optimization while scanning

[Oscar Salvador]

> > +
> 
> This one maybe not necessary.

Yeah, that is a remind of an include file I used for time measurement.
I hope Andrew can drop that if this is taken.

> > /*
> >  * Kmemleak configuration and common defines.
> >  */
> > @@ -1547,11 +1548,14 @@ static void kmemleak_scan(void)
> > unsigned long pfn;
> > 
> > for (pfn = start_pfn; pfn < end_pfn; pfn++) {
> > -   struct page *page;
> > +   struct page *page =
> > pfn_to_online_page(pfn);
> > +
> > +   if (!page)
> > +   continue;
> > 
> > -   if (!pfn_valid(pfn))
> > +   /* only scan pages belonging to this node
> > */
> > +   if (page_to_nid(page) != i)
> > continue;
> 
> Not farmiliar with this situation. Is this often?
Well, hard to tell how often that happens because that mostly depends
on the Hardware in case of baremetal.
Virtual systems can also have it though.

> 
> > -   page = pfn_to_page(pfn);
> > /* only scan if page is in use */
> > if (page_count(page) == 0)
> > continue;
> > -- 
> > 2.13.7
> 
> 
-- 
Oscar Salvador
SUSE L3

Re: [PATCH v2] mailbox: Hi3660: Fixup mailbox state machine malfunction issue

[leo . yan]

On Mon, Dec 03, 2018 at 02:13:08PM +0800, Kevin Wangtao wrote:
> Current mailbox driver of Hi3660 release the mailbox directly
> before sending a new message which may cause last message lost
> and next message sending doesn't take effect actually.
> 
> This patch fixes this issue by following the right process below,
> each time before sending a message, mailbox driver will check
> whether the mailbox is in ready state, if last message has been
> acknowledged, mailbox driver will clear the ack state to turn
> the mailbox to ready state again.
> 
> Signed-off-by: Kevin Wangtao 

Thanks for sending out this patch, Kevin.

I tested this patch at my side with two cases (one is dhry2 for
performance testing for every OPPs, and another is stress test
two clusters frequency change concurrently), both of them can
pass after applied this patch.

Reviewed-and-tested-by: Leo Yan 

Jassi, please review and pick it up if it's okay for you.

Thanks,
Leo Yan

> ---
> Changes v1 -> v2:
>  - update commit message
> 
>  drivers/mailbox/hi3660-mailbox.c | 22 ++
>  1 file changed, 10 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/mailbox/hi3660-mailbox.c 
> b/drivers/mailbox/hi3660-mailbox.c
> index 3eea6b6..035b71a 100644
> --- a/drivers/mailbox/hi3660-mailbox.c
> +++ b/drivers/mailbox/hi3660-mailbox.c
> @@ -38,6 +38,7 @@
>  #define MBOX_AUTOMATIC_ACK   1
>  
>  #define MBOX_STATE_IDLE  BIT(4)
> +#define MBOX_STATE_READY BIT(5)
>  #define MBOX_STATE_ACK   BIT(7)
>  
>  #define MBOX_MSG_LEN 8
> @@ -91,8 +92,8 @@ static int hi3660_mbox_check_state(struct mbox_chan *chan)
>   unsigned long val;
>   unsigned int ret;
>  
> - /* Mailbox is idle so directly bail out */
> - if (readl(base + MBOX_MODE_REG) & MBOX_STATE_IDLE)
> + /* Mailbox is ready to use */
> + if (readl(base + MBOX_MODE_REG) & MBOX_STATE_READY)
>   return 0;
>  
>   /* Wait for acknowledge from remote */
> @@ -103,9 +104,9 @@ static int hi3660_mbox_check_state(struct mbox_chan *chan)
>   return ret;
>   }
>  
> - /* Ensure channel is released */
> - writel(0x, base + MBOX_IMASK_REG);
> - writel(BIT(mchan->ack_irq), base + MBOX_SRC_REG);
> + /* clear ack state, mailbox will get back to ready state */
> + writel(BIT(mchan->ack_irq), base + MBOX_ICLR_REG);
> +
>   return 0;
>  }
>  
> @@ -160,10 +161,6 @@ static int hi3660_mbox_startup(struct mbox_chan *chan)
>  {
>   int ret;
>  
> - ret = hi3660_mbox_check_state(chan);
> - if (ret)
> - return ret;
> -
>   ret = hi3660_mbox_unlock(chan);
>   if (ret)
>   return ret;
> @@ -183,10 +180,11 @@ static int hi3660_mbox_send_data(struct mbox_chan 
> *chan, void *msg)
>   void __iomem *base = MBOX_BASE(mbox, ch);
>   u32 *buf = msg;
>   unsigned int i;
> + int ret;
>  
> - /* Ensure channel is released */
> - writel_relaxed(0x, base + MBOX_IMASK_REG);
> - writel_relaxed(BIT(mchan->ack_irq), base + MBOX_SRC_REG);
> + ret = hi3660_mbox_check_state(chan);
> + if (ret)
> + return ret;
>  
>   /* Clear mask for destination interrupt */
>   writel_relaxed(~BIT(mchan->dst_irq), base + MBOX_IMASK_REG);
> -- 
> 2.8.1
> 

Re: [PATCH v2] mailbox: Hi3660: Fixup mailbox state machine malfunction issue

[leo . yan]

On Mon, Dec 03, 2018 at 02:13:08PM +0800, Kevin Wangtao wrote:
> Current mailbox driver of Hi3660 release the mailbox directly
> before sending a new message which may cause last message lost
> and next message sending doesn't take effect actually.
> 
> This patch fixes this issue by following the right process below,
> each time before sending a message, mailbox driver will check
> whether the mailbox is in ready state, if last message has been
> acknowledged, mailbox driver will clear the ack state to turn
> the mailbox to ready state again.
> 
> Signed-off-by: Kevin Wangtao 

Thanks for sending out this patch, Kevin.

I tested this patch at my side with two cases (one is dhry2 for
performance testing for every OPPs, and another is stress test
two clusters frequency change concurrently), both of them can
pass after applied this patch.

Reviewed-and-tested-by: Leo Yan 

Jassi, please review and pick it up if it's okay for you.

Thanks,
Leo Yan

> ---
> Changes v1 -> v2:
>  - update commit message
> 
>  drivers/mailbox/hi3660-mailbox.c | 22 ++
>  1 file changed, 10 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/mailbox/hi3660-mailbox.c 
> b/drivers/mailbox/hi3660-mailbox.c
> index 3eea6b6..035b71a 100644
> --- a/drivers/mailbox/hi3660-mailbox.c
> +++ b/drivers/mailbox/hi3660-mailbox.c
> @@ -38,6 +38,7 @@
>  #define MBOX_AUTOMATIC_ACK   1
>  
>  #define MBOX_STATE_IDLE  BIT(4)
> +#define MBOX_STATE_READY BIT(5)
>  #define MBOX_STATE_ACK   BIT(7)
>  
>  #define MBOX_MSG_LEN 8
> @@ -91,8 +92,8 @@ static int hi3660_mbox_check_state(struct mbox_chan *chan)
>   unsigned long val;
>   unsigned int ret;
>  
> - /* Mailbox is idle so directly bail out */
> - if (readl(base + MBOX_MODE_REG) & MBOX_STATE_IDLE)
> + /* Mailbox is ready to use */
> + if (readl(base + MBOX_MODE_REG) & MBOX_STATE_READY)
>   return 0;
>  
>   /* Wait for acknowledge from remote */
> @@ -103,9 +104,9 @@ static int hi3660_mbox_check_state(struct mbox_chan *chan)
>   return ret;
>   }
>  
> - /* Ensure channel is released */
> - writel(0x, base + MBOX_IMASK_REG);
> - writel(BIT(mchan->ack_irq), base + MBOX_SRC_REG);
> + /* clear ack state, mailbox will get back to ready state */
> + writel(BIT(mchan->ack_irq), base + MBOX_ICLR_REG);
> +
>   return 0;
>  }
>  
> @@ -160,10 +161,6 @@ static int hi3660_mbox_startup(struct mbox_chan *chan)
>  {
>   int ret;
>  
> - ret = hi3660_mbox_check_state(chan);
> - if (ret)
> - return ret;
> -
>   ret = hi3660_mbox_unlock(chan);
>   if (ret)
>   return ret;
> @@ -183,10 +180,11 @@ static int hi3660_mbox_send_data(struct mbox_chan 
> *chan, void *msg)
>   void __iomem *base = MBOX_BASE(mbox, ch);
>   u32 *buf = msg;
>   unsigned int i;
> + int ret;
>  
> - /* Ensure channel is released */
> - writel_relaxed(0x, base + MBOX_IMASK_REG);
> - writel_relaxed(BIT(mchan->ack_irq), base + MBOX_SRC_REG);
> + ret = hi3660_mbox_check_state(chan);
> + if (ret)
> + return ret;
>  
>   /* Clear mask for destination interrupt */
>   writel_relaxed(~BIT(mchan->dst_irq), base + MBOX_IMASK_REG);
> -- 
> 2.8.1
> 

Crypto Fixes for 4.20

[Herbert Xu]

Hi Linus: 

This push fixes the following issues:

- Disable the new crypto stats interface as it's still being changed.
- Fix potential uses-after-free in cbc/cfb/pcbc.


Please pull from

git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus


Herbert Xu (1):
  crypto: user - Disable statistics interface

Pan Bian (1):
  crypto: do not free algorithm before using

 crypto/Kconfig | 2 +-
 crypto/cbc.c   | 6 --
 crypto/cfb.c   | 6 --
 crypto/pcbc.c  | 6 --
 4 files changed, 13 insertions(+), 7 deletions(-)

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH v4 5/5] powerpc: generate uapi header and system call table files

[Firoz Khan]

System call table generation script must be run to gener-
ate unistd_32/64.h and syscall_table_32/64/c32/spu.h files.
This patch will have changes which will invokes the script.

This patch will generate unistd_32/64.h and syscall_table-
_32/64/c32/spu.h files by the syscall table generation
script invoked by parisc/Makefile and the generated files
against the removed files must be identical.

The generated uapi header file will be included in uapi/-
asm/unistd.h and generated system call table header file
will be included by kernel/systbl.S file.

Signed-off-by: Firoz Khan 
---
 arch/powerpc/Makefile   |   3 +
 arch/powerpc/include/asm/Kbuild |   4 +
 arch/powerpc/include/asm/systbl.h   | 395 
 arch/powerpc/include/uapi/asm/Kbuild|   2 +
 arch/powerpc/include/uapi/asm/unistd.h  | 392 +--
 arch/powerpc/kernel/Makefile|  10 -
 arch/powerpc/kernel/systbl.S|  52 +---
 arch/powerpc/kernel/systbl_chk.c|  60 -
 arch/powerpc/platforms/cell/spu_callbacks.c |  17 +-
 9 files changed, 26 insertions(+), 909 deletions(-)
 delete mode 100644 arch/powerpc/include/asm/systbl.h
 delete mode 100644 arch/powerpc/kernel/systbl_chk.c

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 8a2ce14..34897191 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -402,6 +402,9 @@ archclean:
 
 archprepare: checkbin
 
+archheaders:
+   $(Q)$(MAKE) $(build)=arch/powerpc/kernel/syscalls all
+
 ifdef CONFIG_STACKPROTECTOR
 prepare: stack_protector_prepare
 
diff --git a/arch/powerpc/include/asm/Kbuild b/arch/powerpc/include/asm/Kbuild
index 3196d22..77ff7fb 100644
--- a/arch/powerpc/include/asm/Kbuild
+++ b/arch/powerpc/include/asm/Kbuild
@@ -1,3 +1,7 @@
+generated-y += syscall_table_32.h
+generated-y += syscall_table_64.h
+generated-y += syscall_table_c32.h
+generated-y += syscall_table_spu.h
 generic-y += div64.h
 generic-y += export.h
 generic-y += irq_regs.h
diff --git a/arch/powerpc/include/asm/systbl.h 
b/arch/powerpc/include/asm/systbl.h
deleted file mode 100644
index c4321b9..000
--- a/arch/powerpc/include/asm/systbl.h
+++ /dev/null
@@ -1,395 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * List of powerpc syscalls. For the meaning of the _SPU suffix see
- * arch/powerpc/platforms/cell/spu_callbacks.c
- */
-
-SYSCALL(restart_syscall)
-SYSCALL(exit)
-PPC_SYS(fork)
-SYSCALL_SPU(read)
-SYSCALL_SPU(write)
-COMPAT_SYS_SPU(open)
-SYSCALL_SPU(close)
-SYSCALL_SPU(waitpid)
-SYSCALL_SPU(creat)
-SYSCALL_SPU(link)
-SYSCALL_SPU(unlink)
-COMPAT_SYS(execve)
-SYSCALL_SPU(chdir)
-COMPAT_SYS_SPU(time)
-SYSCALL_SPU(mknod)
-SYSCALL_SPU(chmod)
-SYSCALL_SPU(lchown)
-SYSCALL(ni_syscall)
-OLDSYS(stat)
-COMPAT_SYS_SPU(lseek)
-SYSCALL_SPU(getpid)
-COMPAT_SYS(mount)
-SYSX(sys_ni_syscall,sys_oldumount,sys_oldumount)
-SYSCALL_SPU(setuid)
-SYSCALL_SPU(getuid)
-COMPAT_SYS_SPU(stime)
-COMPAT_SYS(ptrace)
-SYSCALL_SPU(alarm)
-OLDSYS(fstat)
-SYSCALL(pause)
-COMPAT_SYS(utime)
-SYSCALL(ni_syscall)
-SYSCALL(ni_syscall)
-SYSCALL_SPU(access)
-SYSCALL_SPU(nice)
-SYSCALL(ni_syscall)
-SYSCALL_SPU(sync)
-SYSCALL_SPU(kill)
-SYSCALL_SPU(rename)
-SYSCALL_SPU(mkdir)
-SYSCALL_SPU(rmdir)
-SYSCALL_SPU(dup)
-SYSCALL_SPU(pipe)
-COMPAT_SYS_SPU(times)
-SYSCALL(ni_syscall)
-SYSCALL_SPU(brk)
-SYSCALL_SPU(setgid)
-SYSCALL_SPU(getgid)
-SYSCALL(signal)
-SYSCALL_SPU(geteuid)
-SYSCALL_SPU(getegid)
-SYSCALL(acct)
-SYSCALL(umount)
-SYSCALL(ni_syscall)
-COMPAT_SYS_SPU(ioctl)
-COMPAT_SYS_SPU(fcntl)
-SYSCALL(ni_syscall)
-SYSCALL_SPU(setpgid)
-SYSCALL(ni_syscall)
-SYSX(sys_ni_syscall,sys_olduname,sys_olduname)
-SYSCALL_SPU(umask)
-SYSCALL_SPU(chroot)
-COMPAT_SYS(ustat)
-SYSCALL_SPU(dup2)
-SYSCALL_SPU(getppid)
-SYSCALL_SPU(getpgrp)
-SYSCALL_SPU(setsid)
-SYS32ONLY(sigaction)
-SYSCALL_SPU(sgetmask)
-SYSCALL_SPU(ssetmask)
-SYSCALL_SPU(setreuid)
-SYSCALL_SPU(setregid)
-SYS32ONLY(sigsuspend)
-SYSX(sys_ni_syscall,compat_sys_sigpending,sys_sigpending)
-SYSCALL_SPU(sethostname)
-COMPAT_SYS_SPU(setrlimit)
-SYSX(sys_ni_syscall,compat_sys_old_getrlimit,sys_old_getrlimit)
-COMPAT_SYS_SPU(getrusage)
-COMPAT_SYS_SPU(gettimeofday)
-COMPAT_SYS_SPU(settimeofday)
-SYSCALL_SPU(getgroups)
-SYSCALL_SPU(setgroups)
-SYSX(sys_ni_syscall,sys_ni_syscall,ppc_select)
-SYSCALL_SPU(symlink)
-OLDSYS(lstat)
-SYSCALL_SPU(readlink)
-SYSCALL(uselib)
-SYSCALL(swapon)
-SYSCALL(reboot)
-SYSX(sys_ni_syscall,compat_sys_old_readdir,sys_old_readdir)
-SYSCALL_SPU(mmap)
-SYSCALL_SPU(munmap)
-COMPAT_SYS_SPU(truncate)
-COMPAT_SYS_SPU(ftruncate)
-SYSCALL_SPU(fchmod)
-SYSCALL_SPU(fchown)
-SYSCALL_SPU(getpriority)
-SYSCALL_SPU(setpriority)
-SYSCALL(ni_syscall)
-COMPAT_SYS(statfs)
-COMPAT_SYS(fstatfs)
-SYSCALL(ni_syscall)
-COMPAT_SYS_SPU(socketcall)
-SYSCALL_SPU(syslog)
-COMPAT_SYS_SPU(setitimer)
-COMPAT_SYS_SPU(getitimer)
-COMPAT_SYS_SPU(newstat)
-COMPAT_SYS_SPU(newlstat)
-COMPAT_SYS_SPU(newfstat)
-SYSX(sys_ni_syscall,sys_uname,sys_uname)

[PATCH v4 3/5] powerpc: add system call table generation support

[Firoz Khan]

The system call tables are in different format in all
architecture and it will be difficult to manually add or
modify the system calls in the respective files. To make
it easy by keeping a script and which will generate the
uapi header and syscall table file. This change will also
help to unify the implementation across all architectures.

The system call table generation script is added in
syscalls directory which contain the script to generate
both uapi header file and system call table files.
The syscall.tbl file will be the input for the scripts.

syscall.tbl contains the list of available system calls
along with system call number and corresponding entry point.
Add a new system call in this architecture will be possible
by adding new entry in the syscall.tbl file.

Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
- Compat entry name, if required.

syscallhdr.sh and syscalltbl.sh will generate uapi header-
unistd_32/64.h and syscall_table_32/64/c32/spu.h files
respectively. File syscall_table_32/64/c32/spu.h is incl-
uded by syscall.S - the real system call table. Both *.sh
files will parse the content syscall.tbl to generate the
header and table files.

ARM, s390 and x86 architecuture does have similar support.
I leverage their implementation to come up with a generic
solution.

Signed-off-by: Firoz Khan 
---
 arch/powerpc/kernel/syscalls/Makefile  |  63 +
 arch/powerpc/kernel/syscalls/syscall.tbl   | 427 +
 arch/powerpc/kernel/syscalls/syscallhdr.sh |  37 +++
 arch/powerpc/kernel/syscalls/syscalltbl.sh |  36 +++
 4 files changed, 563 insertions(+)
 create mode 100644 arch/powerpc/kernel/syscalls/Makefile
 create mode 100644 arch/powerpc/kernel/syscalls/syscall.tbl
 create mode 100644 arch/powerpc/kernel/syscalls/syscallhdr.sh
 create mode 100644 arch/powerpc/kernel/syscalls/syscalltbl.sh

diff --git a/arch/powerpc/kernel/syscalls/Makefile 
b/arch/powerpc/kernel/syscalls/Makefile
new file mode 100644
index 000..27b4895
--- /dev/null
+++ b/arch/powerpc/kernel/syscalls/Makefile
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: GPL-2.0
+kapi := arch/$(SRCARCH)/include/generated/asm
+uapi := arch/$(SRCARCH)/include/generated/uapi/asm
+
+_dummy := $(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)')  \
+ $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)')
+
+syscall := $(srctree)/$(src)/syscall.tbl
+syshdr := $(srctree)/$(src)/syscallhdr.sh
+systbl := $(srctree)/$(src)/syscalltbl.sh
+
+quiet_cmd_syshdr = SYSHDR  $@
+  cmd_syshdr = $(CONFIG_SHELL) '$(syshdr)' '$<' '$@'   \
+  '$(syshdr_abis_$(basetarget))'   \
+  '$(syshdr_pfx_$(basetarget))'\
+  '$(syshdr_offset_$(basetarget))'
+
+quiet_cmd_systbl = SYSTBL  $@
+  cmd_systbl = $(CONFIG_SHELL) '$(systbl)' '$<' '$@'   \
+  '$(systbl_abis_$(basetarget))'   \
+  '$(systbl_abi_$(basetarget))'\
+  '$(systbl_offset_$(basetarget))'
+
+syshdr_abis_unistd_32 := common,nospu,32
+$(uapi)/unistd_32.h: $(syscall) $(syshdr)
+   $(call if_changed,syshdr)
+
+syshdr_abis_unistd_64 := common,nospu,64
+$(uapi)/unistd_64.h: $(syscall) $(syshdr)
+   $(call if_changed,syshdr)
+
+systbl_abis_syscall_table_32 := common,nospu,32
+systbl_abi_syscall_table_32 := 32
+$(kapi)/syscall_table_32.h: $(syscall) $(systbl)
+   $(call if_changed,systbl)
+
+systbl_abis_syscall_table_64 := common,nospu,64
+systbl_abi_syscall_table_64 := 64
+$(kapi)/syscall_table_64.h: $(syscall) $(systbl)
+   $(call if_changed,systbl)
+
+systbl_abis_syscall_table_c32 := common,nospu,32
+systbl_abi_syscall_table_c32 := c32
+$(kapi)/syscall_table_c32.h: $(syscall) $(systbl)
+   $(call if_changed,systbl)
+
+systbl_abis_syscall_table_spu := common,spu
+systbl_abi_syscall_table_spu := spu
+$(kapi)/syscall_table_spu.h: $(syscall) $(systbl)
+   $(call if_changed,systbl)
+
+uapisyshdr-y   += unistd_32.h unistd_64.h
+kapisyshdr-y   += syscall_table_32.h   \
+  syscall_table_64.h   \
+  syscall_table_c32.h  \
+  syscall_table_spu.h
+
+targets+= $(uapisyshdr-y) $(kapisyshdr-y)
+
+PHONY += all
+all: $(addprefix $(uapi)/,$(uapisyshdr-y))
+all: $(addprefix $(kapi)/,$(kapisyshdr-y))
+   @:
diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl 
b/arch/powerpc/kernel/syscalls/syscall.tbl
new file mode 100644
index 000..db3bbb8
--- /dev/null
+++ b/arch/powerpc/kernel/syscalls/syscall.tbl
@@ -0,0 +1,427 @@
+# SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
+#
+# system call numbers and entry vectors for powerpc
+#
+# The format is:
+# 
+#
+# The  can be common, spu, nospu, 64, or 32 for this file.
+#
+0  nospu   restart_syscall sys_restart_syscall

[PATCH v4 4/5] powerpc: split compat syscall table out from native table

[Firoz Khan]

PowerPC uses a syscall table with native and compat calls
interleaved, which is a slightly simpler way to define two
matching tables.

As we move to having the tables generated, that advantage
is no longer important, but the interleaved table gets in
the way of using the same scripts as on the other archit-
ectures.

Split out a new compat_sys_call_table symbol that contains
all the compat calls, and leave the main table for the nat-
ive calls, to more closely match the method we use every-
where else.

Suggested-by: Arnd Bergmann 
Signed-off-by: Firoz Khan 
---
 arch/powerpc/include/asm/syscall.h |  3 +--
 arch/powerpc/kernel/entry_64.S |  7 +--
 arch/powerpc/kernel/systbl.S   | 35 ---
 arch/powerpc/kernel/vdso.c |  7 +--
 4 files changed, 39 insertions(+), 13 deletions(-)

diff --git a/arch/powerpc/include/asm/syscall.h 
b/arch/powerpc/include/asm/syscall.h
index ab9f3f0..1a0e7a8 100644
--- a/arch/powerpc/include/asm/syscall.h
+++ b/arch/powerpc/include/asm/syscall.h
@@ -18,9 +18,8 @@
 #include 
 
 /* ftrace syscalls requires exporting the sys_call_table */
-#ifdef CONFIG_FTRACE_SYSCALLS
 extern const unsigned long sys_call_table[];
-#endif /* CONFIG_FTRACE_SYSCALLS */
+extern const unsigned long compat_sys_call_table[];
 
 static inline int syscall_get_nr(struct task_struct *task, struct pt_regs 
*regs)
 {
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 7b1693a..5574d92 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -54,6 +54,9 @@
 SYS_CALL_TABLE:
.tc sys_call_table[TC],sys_call_table
 
+COMPAT_SYS_CALL_TABLE:
+   .tc compat_sys_call_table[TC],compat_sys_call_table
+
 /* This value is used to mark exception frames on the stack. */
 exception_marker:
.tc ID_EXC_MARKER[TC],STACK_FRAME_REGS_MARKER
@@ -173,7 +176,7 @@ system_call:/* label this so stack 
traces look sane */
ld  r11,SYS_CALL_TABLE@toc(2)
andis.  r10,r10,_TIF_32BIT@h
beq 15f
-   addir11,r11,8   /* use 32-bit syscall entries */
+   ld  r11,COMPAT_SYS_CALL_TABLE@toc(2)
clrldi  r3,r3,32
clrldi  r4,r4,32
clrldi  r5,r5,32
@@ -181,7 +184,7 @@ system_call:/* label this so stack 
traces look sane */
clrldi  r7,r7,32
clrldi  r8,r8,32
 15:
-   slwir0,r0,4
+   slwir0,r0,3
 
barrier_nospec_asm
/*
diff --git a/arch/powerpc/kernel/systbl.S b/arch/powerpc/kernel/systbl.S
index 9ff1913..0fa84e1 100644
--- a/arch/powerpc/kernel/systbl.S
+++ b/arch/powerpc/kernel/systbl.S
@@ -17,13 +17,13 @@
 #include 
 
 #ifdef CONFIG_PPC64
-#define SYSCALL(func)  .8byte  DOTSYM(sys_##func),DOTSYM(sys_##func)
-#define COMPAT_SYS(func)   .8byte  
DOTSYM(sys_##func),DOTSYM(compat_sys_##func)
-#define PPC_SYS(func)  .8byte  DOTSYM(ppc_##func),DOTSYM(ppc_##func)
-#define OLDSYS(func)   .8byte  
DOTSYM(sys_ni_syscall),DOTSYM(sys_ni_syscall)
-#define SYS32ONLY(func).8byte  
DOTSYM(sys_ni_syscall),DOTSYM(compat_sys_##func)
-#define PPC64ONLY(func).8byte  
DOTSYM(ppc_##func),DOTSYM(sys_ni_syscall)
-#define SYSX(f, f3264, f32).8byte  DOTSYM(f),DOTSYM(f3264)
+#define SYSCALL(func)  .8byte  DOTSYM(sys_##func)
+#define COMPAT_SYS(func)   .8byte  DOTSYM(sys_##func)
+#define PPC_SYS(func)  .8byte  DOTSYM(ppc_##func)
+#define OLDSYS(func)   .8byte  DOTSYM(sys_ni_syscall)
+#define SYS32ONLY(func).8byte  DOTSYM(sys_ni_syscall)
+#define PPC64ONLY(func).8byte  DOTSYM(ppc_##func)
+#define SYSX(f, f3264, f32).8byte  DOTSYM(f)
 #else
 #define SYSCALL(func)  .long   sys_##func
 #define COMPAT_SYS(func)   .long   sys_##func
@@ -46,6 +46,27 @@
 
 .globl sys_call_table
 sys_call_table:
+#include 
+
+#undef SYSCALL
+#undef COMPAT_SYS
+#undef PPC_SYS
+#undef OLDSYS
+#undef SYS32ONLY
+#undef PPC64ONLY
+#undef SYSX
 
+#ifdef CONFIG_COMPAT
+#define SYSCALL(func)  .8byte  DOTSYM(sys_##func)
+#define COMPAT_SYS(func)   .8byte  DOTSYM(compat_sys_##func)
+#define PPC_SYS(func)  .8byte  DOTSYM(ppc_##func)
+#define OLDSYS(func)   .8byte  DOTSYM(sys_ni_syscall)
+#define SYS32ONLY(func).8byte  DOTSYM(compat_sys_##func)
+#define PPC64ONLY(func).8byte  DOTSYM(sys_ni_syscall)
+#define SYSX(f, f3264, f32).8byte  DOTSYM(f3264)
+
+.globl compat_sys_call_table
+compat_sys_call_table:
 #define compat_sys_sigsuspend  sys_sigsuspend
 #include 
+#endif
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 65b3bdb..7725a97 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -671,15 +671,18 @@ static void __init vdso_setup_syscall_map(void)
 {
unsigned int i;
extern unsigned long *sys_call_table;
+#ifdef CONFIG_PPC64
+   extern unsigned long 

[PATCH v4 2/5] powerpc: move macro definition from asm/systbl.h

[Firoz Khan]

Move the macro definition for compat_sys_sigsuspend from
asm/systbl.h to the file which it is getting included.

One of the patch in this patch series is generating uapi
header and syscall table files. In order to come up with
a common implimentation across all architecture, we need
to do this change.

This change will simplify the implementation of system
call table generation script and help to come up a common
implementation across all architecture.

Signed-off-by: Firoz Khan 
---
 arch/powerpc/include/asm/systbl.h | 1 -
 arch/powerpc/kernel/systbl.S  | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/systbl.h 
b/arch/powerpc/include/asm/systbl.h
index 01b5171..c4321b9 100644
--- a/arch/powerpc/include/asm/systbl.h
+++ b/arch/powerpc/include/asm/systbl.h
@@ -76,7 +76,6 @@
 SYSCALL_SPU(ssetmask)
 SYSCALL_SPU(setreuid)
 SYSCALL_SPU(setregid)
-#define compat_sys_sigsuspend sys_sigsuspend
 SYS32ONLY(sigsuspend)
 SYSX(sys_ni_syscall,compat_sys_sigpending,sys_sigpending)
 SYSCALL_SPU(sethostname)
diff --git a/arch/powerpc/kernel/systbl.S b/arch/powerpc/kernel/systbl.S
index 919a327..9ff1913 100644
--- a/arch/powerpc/kernel/systbl.S
+++ b/arch/powerpc/kernel/systbl.S
@@ -47,4 +47,5 @@
 .globl sys_call_table
 sys_call_table:
 
+#define compat_sys_sigsuspend  sys_sigsuspend
 #include 
-- 
1.9.1

[PATCH v4 1/5] powerpc: add __NR_syscalls along with NR_syscalls

[Firoz Khan]

NR_syscalls macro holds the number of system call exist
in powerpc architecture. We have to change the value of
NR_syscalls, if we add or delete a system call.

One of the patch in this patch series has a script which
will generate a uapi header based on syscall.tbl file.
The syscall.tbl file contains the number of system call
information. So we have two option to update NR_syscalls
value.

1. Update NR_syscalls in asm/unistd.h manually by count-
   ing the no.of system calls. No need to update NR_sys-
   calls until we either add a new system call or delete
   existing system call.

2. We can keep this feature in above mentioned script,
   that will count the number of syscalls and keep it in
   a generated file. In this case we don't need to expli-
   citly update NR_syscalls in asm/unistd.h file.

The 2nd option will be the recommended one. For that, I
added the __NR_syscalls macro in uapi/asm/unistd.h along
with NR_syscalls asm/unistd.h. The macro __NR_syscalls
also added for making the name convention same across all
architecture. While __NR_syscalls isn't strictly part of
the uapi, having it as part of the generated header to
simplifies the implementation. We also need to enclose
this macro with #ifdef __KERNEL__ to avoid side effects.

Signed-off-by: Firoz Khan 
---
 arch/powerpc/include/asm/unistd.h  | 3 +--
 arch/powerpc/include/uapi/asm/unistd.h | 5 -
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/unistd.h 
b/arch/powerpc/include/asm/unistd.h
index b0de85b..a3c35e6 100644
--- a/arch/powerpc/include/asm/unistd.h
+++ b/arch/powerpc/include/asm/unistd.h
@@ -11,8 +11,7 @@
 
 #include 
 
-
-#define NR_syscalls389
+#define NR_syscalls__NR_syscalls
 
 #define __NR__exit __NR_exit
 
diff --git a/arch/powerpc/include/uapi/asm/unistd.h 
b/arch/powerpc/include/uapi/asm/unistd.h
index 985534d..7195868 100644
--- a/arch/powerpc/include/uapi/asm/unistd.h
+++ b/arch/powerpc/include/uapi/asm/unistd.h
@@ -10,7 +10,6 @@
 #ifndef _UAPI_ASM_POWERPC_UNISTD_H_
 #define _UAPI_ASM_POWERPC_UNISTD_H_
 
-
 #define __NR_restart_syscall 0
 #define __NR_exit1
 #define __NR_fork2
@@ -401,4 +400,8 @@
 #define __NR_rseq  387
 #define __NR_io_pgetevents 388
 
+#ifdef __KERNEL__
+#define __NR_syscalls  389
+#endif
+
 #endif /* _UAPI_ASM_POWERPC_UNISTD_H_ */
-- 
1.9.1

[PATCH v4 0/5] powerpc: system call table generation support

[Firoz Khan]

The purpose of this patch series is, we can easily
add/modify/delete system call table support by cha-
nging entry in syscall.tbl file instead of manually
changing many files. The other goal is to unify the 
system call table generation support implementation 
across all the architectures. 

The system call tables are in different format in 
all architecture. It will be difficult to manually
add, modify or delete the system calls in the resp-
ective files manually. To make it easy by keeping a 
script and which'll generate uapi header file and 
syscall table file.

syscall.tbl contains the list of available system 
calls along with system call number and correspond-
ing entry point. Add a new system call in this arch-
itecture will be possible by adding new entry in 
the syscall.tbl file.

Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
- Compat entry name, if required.
- spu entry name, if required.

ARM, s390 and x86 architecuture does exist the sim-
ilar support. I leverage their implementation to 
come up with a generic solution.

I have done the same support for work for alpha, 
ia64, m68k, microblaze, mips, parisc, sh, sparc, 
and xtensa. Below mentioned git repository contains
more details about the workflow.

https://github.com/frzkhn/system_call_table_generator/

Finally, this is the ground work to solve the Y2038
issue. We need to add two dozen of system calls to 
solve Y2038 issue. So this patch series will help to
add new system calls easily by adding new entry in the
syscall.tbl.

Changes since v3:
 - split compat syscall table out from native table.
 - modified the script to add new line in the generated
   file.

Changes since v2:
 - modified/optimized the syscall.tbl to avoid duplicate
   for the spu entries.
 - updated the syscalltbl.sh to meet the above point.

Changes since v1:
 - optimized/updated the syscall table generation 
   scripts.
 - fixed all mixed indentation issues in syscall.tbl.
 - added "comments" in syscall_*.tbl.
 - changed from generic-y to generated-y in Kbuild.

Firoz Khan (5):
  powerpc: add __NR_syscalls along with NR_syscalls
  powerpc: move macro definition from asm/systbl.h
  powerpc: add system call table generation support
  powerpc: split compat syscall table out from native table
  powerpc: generate uapi header and system call table files

 arch/powerpc/Makefile   |   3 +
 arch/powerpc/include/asm/Kbuild |   4 +
 arch/powerpc/include/asm/syscall.h  |   3 +-
 arch/powerpc/include/asm/systbl.h   | 396 --
 arch/powerpc/include/asm/unistd.h   |   3 +-
 arch/powerpc/include/uapi/asm/Kbuild|   2 +
 arch/powerpc/include/uapi/asm/unistd.h  | 389 +
 arch/powerpc/kernel/Makefile|  10 -
 arch/powerpc/kernel/entry_64.S  |   7 +-
 arch/powerpc/kernel/syscalls/Makefile   |  63 
 arch/powerpc/kernel/syscalls/syscall.tbl| 427 
 arch/powerpc/kernel/syscalls/syscallhdr.sh  |  37 +++
 arch/powerpc/kernel/syscalls/syscalltbl.sh  |  36 +++
 arch/powerpc/kernel/systbl.S|  40 ++-
 arch/powerpc/kernel/systbl_chk.c|  60 
 arch/powerpc/kernel/vdso.c  |   7 +-
 arch/powerpc/platforms/cell/spu_callbacks.c |  17 +-
 17 files changed, 606 insertions(+), 898 deletions(-)
 delete mode 100644 arch/powerpc/include/asm/systbl.h
 create mode 100644 arch/powerpc/kernel/syscalls/Makefile
 create mode 100644 arch/powerpc/kernel/syscalls/syscall.tbl
 create mode 100644 arch/powerpc/kernel/syscalls/syscallhdr.sh
 create mode 100644 arch/powerpc/kernel/syscalls/syscalltbl.sh
 delete mode 100644 arch/powerpc/kernel/systbl_chk.c

-- 
1.9.1

RE: [PATCH v7 09/10] usb: dwc3: Check for IOC/LST bit in both event->status and TRB->ctrl fields

[Felipe Balbi]

Hi,

Anurag Kumar Vulisha  writes:
>>> @@ -2286,7 +2286,12 @@ static int
>>dwc3_gadget_ep_reclaim_completed_trb(struct dwc3_ep *dep,
>>> if (event->status & DEPEVT_STATUS_SHORT && !chain)
>>> return 1;
>>>
>>> -   if (event->status & (DEPEVT_STATUS_IOC | DEPEVT_STATUS_LST))
>>> +   if ((event->status & DEPEVT_STATUS_IOC) &&
>>> +   (trb->ctrl & DWC3_TRB_CTRL_IOC))
>>> +   return 1;
>>
>>this shouldn't be necessary. According to databook, event->status
>>contains the bits from the completed TRB.  Which means that
>>event->status & IOC will always be equal to trb->ctrl & IOC.
>>
> Thanks for reviewing this patch. Lets consider an example where a request
> has num_sgs > 0 and each sg is mapped to a TRB and the last TRB has the
> IOC bit set. Once the controller is done with the transfer, it  generates 
> XferInProgress for the last TRB (since IOC bit is set). As a part of trb 
> reclaim
> process  dwc3_gadget_ep_reclaim_trb_sg() calls
> dwc3_gadget_ep_reclaim_completed_trb() for req->num_sgs times. Since
> the event already has the IOC bit set, the loop is exited from the loop at the
> very first TRB and the remaining TRBs (mapped to the sglist) are left 
> unhandled.
> To avoid this we modified the code to exit only if both TRB & event has the 
> IOC
> bit set.

Seems like IOC case should just test for chain flag as well:

modified   drivers/usb/dwc3/gadget.c
@@ -2372,7 +2372,7 @@ static int dwc3_gadget_ep_reclaim_completed_trb(struct 
dwc3_ep *dep,
if (event->status & DEPEVT_STATUS_SHORT && !chain)
return 1;
 
-   if (event->status & DEPEVT_STATUS_IOC)
+   if (event->status & DEPEVT_STATUS_IOC && !chain)
return 1;
 
return 0;

-- 
balbi

Re: [PATCH] mm, kmemleak: Little optimization while scanning

[Oscar Salvador]

I just realized I forgot to add that this was suggested by Michal.
Sorry, I was a but rushy.

On Thu, 2018-12-06 at 14:19 +0100, Oscar Salvador wrote:
> kmemleak_scan() goes through all online nodes and tries
> to scan all used pages.
> We can do better and use pfn_to_online_page(), so in case we have
> CONFIG_MEMORY_HOTPLUG, offlined pages will be skiped automatically.
> For boxes where CONFIG_MEMORY_HOTPLUG is not present,
> pfn_to_online_page()
> will fallback to pfn_valid().
> 
> Another little optimization is to check if the page belongs to the
> node
> we are currently checking, so in case we have nodes interleaved we
> will
> not check the same pfn multiple times.
> 
> I ran some tests:
> 
> Add some memory to node1 and node2 making it interleaved:
> 
> (qemu) object_add memory-backend-ram,id=ram0,size=1G
> (qemu) device_add pc-dimm,id=dimm0,memdev=ram0,node=1
> (qemu) object_add memory-backend-ram,id=ram1,size=1G
> (qemu) device_add pc-dimm,id=dimm1,memdev=ram1,node=2
> (qemu) object_add memory-backend-ram,id=ram2,size=1G
> (qemu) device_add pc-dimm,id=dimm2,memdev=ram2,node=1
> 
> Then, we offline that memory:
>  # for i in {32..39} ; do echo "offline" >
> /sys/devices/system/node/node1/memory$i/state;done
>  # for i in {48..55} ; do echo "offline" >
> /sys/devices/system/node/node1/memory$i/state;don
>  # for i in {40..47} ; do echo "offline" >
> /sys/devices/system/node/node2/memory$i/state;done
> 
> And we run kmemleak_scan:
> 
>  # echo "scan" > /sys/kernel/debug/kmemleak
> 
> before the patch:
> 
> kmemleak: time spend: 41596 us
> 
> after the patch:
> 
> kmemleak: time spend: 34899 us
> 
> Signed-off-by: Oscar Salvador 
Suggested-by: Michal Hocko 

> ---
>  mm/kmemleak.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/kmemleak.c b/mm/kmemleak.c
> index 877de4fa0720..5ce1e6a46d77 100644
> --- a/mm/kmemleak.c
> +++ b/mm/kmemleak.c
> @@ -113,6 +113,7 @@
>  #include 
>  #include 
>  
> +
>  /*
>   * Kmemleak configuration and common defines.
>   */
> @@ -1547,11 +1548,14 @@ static void kmemleak_scan(void)
>   unsigned long pfn;
>  
>   for (pfn = start_pfn; pfn < end_pfn; pfn++) {
> - struct page *page;
> + struct page *page = pfn_to_online_page(pfn);
> +
> + if (!page)
> + continue;
>  
> - if (!pfn_valid(pfn))
> + /* only scan pages belonging to this node */
> + if (page_to_nid(page) != i)
>   continue;
> - page = pfn_to_page(pfn);
>   /* only scan if page is in use */
>   if (page_count(page) == 0)
>   continue;
-- 
Oscar Salvador
SUSE L3