date:20180817

Hi Boris,

Thanks for the review.

> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Friday, August 17, 2018 11:29 PM
> To: Naga Sureshkumar Relli 
> Cc: miquel.ray...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> computersforpe...@gmail.com; marek.va...@gmail.com; kyungmin.p...@samsung.com;
> abs...@codeaurora.org; peterpand...@micron.com; frieder.schre...@exceet.de; 
> linux-
> m...@lists.infradead.org; linux-kernel@vger.kernel.org; Michal Simek 
> ;
> nagasureshkumarre...@gmail.com
> Subject: Re: [LINUX PATCH v10 2/2] mtd: rawnand: arasan: Add support for 
> Arasan
> NAND Flash Controller
> 
> Hi Naga,
> 
> On Fri, 17 Aug 2018 18:49:24 +0530
> Naga Sureshkumar Relli  wrote:
> 
> > +static int anfc_exec_op_cmd(struct nand_chip *chip,
> > +  const struct nand_subop *subop) {
> > +   const struct nand_op_instr *instr;
> > +   struct anfc_op nfc_op = {};
> > +   struct anfc_nand_chip *achip = to_anfc_nand(chip);
> > +   struct anfc_nand_controller *nfc = to_anfc(chip->controller);
> > +   struct mtd_info *mtd = nand_to_mtd(chip);
> > +   u32 addrcycles;
> > +   unsigned int op_id, len = 0;
> > +   bool reading;
> > +
> > +   anfc_parse_instructions(chip, subop, _op);
> > +   instr = nfc_op.data_instr;
> > +   op_id = nfc_op.data_instr_idx;
> > +   if (nfc_op.data_instr)
> > +   len = nand_subop_get_data_len(subop, op_id);
> > +
> > +   /*
> > +* The switch case is to prepare a command and to set page/column
> > +* address. Arasan NAND controller has program register(Off: 0x10)),
> > +* which needs to be set for every command.
> > +* Ex: When NAND_CMD_RESET is issued, then we need to set reset bit
> > +* in program_register. etc..
> > +*/
> > +   switch (nfc_op.cmnds[0]) {
> > +   case NAND_CMD_SEQIN:
> > +   addrcycles = achip->raddr_cycles + achip->caddr_cycles;
> > +
> > +   anfc_prepare_cmd(nfc, nfc_op.cmnds[0], NAND_CMD_PAGEPROG, 1,
> > +mtd->writesize, addrcycles);
> > +   anfc_setpagecoladdr(nfc, nfc_op.row, nfc_op.col);
> > +   break;
> > +   case NAND_CMD_READOOB:
> > +   nfc_op.col += mtd->writesize;
> > +   case NAND_CMD_READ0:
> > +   case NAND_CMD_READ1:
> > +   addrcycles = achip->raddr_cycles + achip->caddr_cycles;
> > +   anfc_prepare_cmd(nfc, NAND_CMD_READ0, NAND_CMD_READSTART,
> 1,
> > +mtd->writesize, addrcycles);
> > +   anfc_setpagecoladdr(nfc, nfc_op.row, nfc_op.col);
> > +   if (!nfc_op.data_instr)
> > +   return 0;
> > +
> > +   anfc_read_data_op(mtd, instr->ctx.data.buf.in, len);
> > +   break;
> > +   case NAND_CMD_RNDOUT:
> > +   anfc_prepare_cmd(nfc, nfc_op.cmnds[0], NAND_CMD_RNDOUTSTART, 1,
> > +mtd->writesize, 2);
> > +   anfc_setpagecoladdr(nfc, nfc_op.row, nfc_op.col);
> > +   nfc->prog = PROG_PGRD;
> > +   break;
> > +   case NAND_CMD_PARAM:
> > +   anfc_prepare_cmd(nfc, nfc_op.cmnds[0], 0, 0, 0, 1);
> > +   anfc_setpagecoladdr(nfc, nfc_op.row, nfc_op.col);
> > +   nfc->prog = PROG_RDPARAM;
> > +   break;
> > +   case NAND_CMD_READID:
> > +   anfc_prepare_cmd(nfc, nfc_op.cmnds[0], 0, 0, 0, 1);
> > +   anfc_setpagecoladdr(nfc, nfc_op.row, nfc_op.col);
> > +   nfc->prog = PROG_RDID;
> > +   break;
> > +   case NAND_CMD_GET_FEATURES:
> > +   anfc_prepare_cmd(nfc, nfc_op.cmnds[0], 0, 0, 0, 1);
> > +   anfc_setpagecoladdr(nfc, nfc_op.row, nfc_op.col);
> > +   nfc->prog = PROG_GET_FEATURE;
> > +   break;
> > +   case NAND_CMD_SET_FEATURES:
> > +   anfc_prepare_cmd(nfc, nfc_op.cmnds[0], 0, 0, 0, 1);
> > +   anfc_setpagecoladdr(nfc, nfc_op.row, nfc_op.col);
> > +   nfc->prog = PROG_SET_FEATURE;
> > +   break;
> > +   case NAND_CMD_ERASE1:
> > +   anfc_erase_function(chip, nfc_op);
> > +   break;
> > +   default:
> > +   break;
> > +   }
> 
> Looks like you have one of these smart controllers where everything is 
> hardcoded and new
> commands (like vendor specific commands) can't be supported, and we're back 
> to abusing -
> >exec_op(), just like ->cmdfunc() was abused.
Actually hardcoding commands with ->exec_op() interface in the driver is really 
looking weird.
I agree with that.
But as per the spec, for every command, we need to set respective bit in 
PROG_REG and because
Of this, we need to track the commands for each exec_op() call.
> 
> Don't you have a way to send raw CMD/ADDR/DATA cycles? If not, then we'll 
> have to
> consider other options, because I don't want to go back to the situation we 
> are in with -
> >cmdfunc().
As I said above, for each command we need to set a bit in PROG_REG, to initiate 
the operation.
The only conflicting thing is that, setting a respective bit in PROG_REG based

RE: [LINUX PATCH v10 2/2] mtd: rawnand: arasan: Add support for Arasan NAND Flash Controller

Hi Boris,

Thanks for the review.

> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Friday, August 17, 2018 11:29 PM
> To: Naga Sureshkumar Relli 
> Cc: miquel.ray...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> computersforpe...@gmail.com; marek.va...@gmail.com; kyungmin.p...@samsung.com;
> abs...@codeaurora.org; peterpand...@micron.com; frieder.schre...@exceet.de; 
> linux-
> m...@lists.infradead.org; linux-kernel@vger.kernel.org; Michal Simek 
> ;
> nagasureshkumarre...@gmail.com
> Subject: Re: [LINUX PATCH v10 2/2] mtd: rawnand: arasan: Add support for 
> Arasan
> NAND Flash Controller
> 
> Hi Naga,
> 
> On Fri, 17 Aug 2018 18:49:24 +0530
> Naga Sureshkumar Relli  wrote:
> 
> > +static int anfc_exec_op_cmd(struct nand_chip *chip,
> > +  const struct nand_subop *subop) {
> > +   const struct nand_op_instr *instr;
> > +   struct anfc_op nfc_op = {};
> > +   struct anfc_nand_chip *achip = to_anfc_nand(chip);
> > +   struct anfc_nand_controller *nfc = to_anfc(chip->controller);
> > +   struct mtd_info *mtd = nand_to_mtd(chip);
> > +   u32 addrcycles;
> > +   unsigned int op_id, len = 0;
> > +   bool reading;
> > +
> > +   anfc_parse_instructions(chip, subop, _op);
> > +   instr = nfc_op.data_instr;
> > +   op_id = nfc_op.data_instr_idx;
> > +   if (nfc_op.data_instr)
> > +   len = nand_subop_get_data_len(subop, op_id);
> > +
> > +   /*
> > +* The switch case is to prepare a command and to set page/column
> > +* address. Arasan NAND controller has program register(Off: 0x10)),
> > +* which needs to be set for every command.
> > +* Ex: When NAND_CMD_RESET is issued, then we need to set reset bit
> > +* in program_register. etc..
> > +*/
> > +   switch (nfc_op.cmnds[0]) {
> > +   case NAND_CMD_SEQIN:
> > +   addrcycles = achip->raddr_cycles + achip->caddr_cycles;
> > +
> > +   anfc_prepare_cmd(nfc, nfc_op.cmnds[0], NAND_CMD_PAGEPROG, 1,
> > +mtd->writesize, addrcycles);
> > +   anfc_setpagecoladdr(nfc, nfc_op.row, nfc_op.col);
> > +   break;
> > +   case NAND_CMD_READOOB:
> > +   nfc_op.col += mtd->writesize;
> > +   case NAND_CMD_READ0:
> > +   case NAND_CMD_READ1:
> > +   addrcycles = achip->raddr_cycles + achip->caddr_cycles;
> > +   anfc_prepare_cmd(nfc, NAND_CMD_READ0, NAND_CMD_READSTART,
> 1,
> > +mtd->writesize, addrcycles);
> > +   anfc_setpagecoladdr(nfc, nfc_op.row, nfc_op.col);
> > +   if (!nfc_op.data_instr)
> > +   return 0;
> > +
> > +   anfc_read_data_op(mtd, instr->ctx.data.buf.in, len);
> > +   break;
> > +   case NAND_CMD_RNDOUT:
> > +   anfc_prepare_cmd(nfc, nfc_op.cmnds[0], NAND_CMD_RNDOUTSTART, 1,
> > +mtd->writesize, 2);
> > +   anfc_setpagecoladdr(nfc, nfc_op.row, nfc_op.col);
> > +   nfc->prog = PROG_PGRD;
> > +   break;
> > +   case NAND_CMD_PARAM:
> > +   anfc_prepare_cmd(nfc, nfc_op.cmnds[0], 0, 0, 0, 1);
> > +   anfc_setpagecoladdr(nfc, nfc_op.row, nfc_op.col);
> > +   nfc->prog = PROG_RDPARAM;
> > +   break;
> > +   case NAND_CMD_READID:
> > +   anfc_prepare_cmd(nfc, nfc_op.cmnds[0], 0, 0, 0, 1);
> > +   anfc_setpagecoladdr(nfc, nfc_op.row, nfc_op.col);
> > +   nfc->prog = PROG_RDID;
> > +   break;
> > +   case NAND_CMD_GET_FEATURES:
> > +   anfc_prepare_cmd(nfc, nfc_op.cmnds[0], 0, 0, 0, 1);
> > +   anfc_setpagecoladdr(nfc, nfc_op.row, nfc_op.col);
> > +   nfc->prog = PROG_GET_FEATURE;
> > +   break;
> > +   case NAND_CMD_SET_FEATURES:
> > +   anfc_prepare_cmd(nfc, nfc_op.cmnds[0], 0, 0, 0, 1);
> > +   anfc_setpagecoladdr(nfc, nfc_op.row, nfc_op.col);
> > +   nfc->prog = PROG_SET_FEATURE;
> > +   break;
> > +   case NAND_CMD_ERASE1:
> > +   anfc_erase_function(chip, nfc_op);
> > +   break;
> > +   default:
> > +   break;
> > +   }
> 
> Looks like you have one of these smart controllers where everything is 
> hardcoded and new
> commands (like vendor specific commands) can't be supported, and we're back 
> to abusing -
> >exec_op(), just like ->cmdfunc() was abused.
Actually hardcoding commands with ->exec_op() interface in the driver is really 
looking weird.
I agree with that.
But as per the spec, for every command, we need to set respective bit in 
PROG_REG and because
Of this, we need to track the commands for each exec_op() call.
> 
> Don't you have a way to send raw CMD/ADDR/DATA cycles? If not, then we'll 
> have to
> consider other options, because I don't want to go back to the situation we 
> are in with -
> >cmdfunc().
As I said above, for each command we need to set a bit in PROG_REG, to initiate 
the operation.
The only conflicting thing is that, setting a respective bit in PROG_REG based

Request for Partnership-

2018-08-17 Thread Juan Carlos

Sir/Madam,
 
I have access to very vital information that can be used to move huge amount of 
money. I have done my homework very well and i have the machineries in place to 
get it done since I am still in active service. If it was possible for me to do 
it alone I would not have bothered contacting you. Ultimately I need you to 
play an important role in the completion of this business transaction.
 
Reply if you are willing to do the business.
 
Regards,
Juan Carlos

Request for Partnership-

2018-08-17 Thread Juan Carlos

Sir/Madam,
 
I have access to very vital information that can be used to move huge amount of 
money. I have done my homework very well and i have the machineries in place to 
get it done since I am still in active service. If it was possible for me to do 
it alone I would not have bothered contacting you. Ultimately I need you to 
play an important role in the completion of this business transaction.
 
Reply if you are willing to do the business.
 
Regards,
Juan Carlos

RE: [LINUX PATCH v10 2/2] mtd: rawnand: arasan: Add support for Arasan NAND Flash Controller

Hi Miquel,

Thanks for the review.

> -Original Message-
> From: Miquel Raynal [mailto:miquel.ray...@bootlin.com]
> Sent: Friday, August 17, 2018 8:08 PM
> To: Naga Sureshkumar Relli 
> Cc: boris.brezil...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> computersforpe...@gmail.com; marek.va...@gmail.com; kyungmin.p...@samsung.com;
> abs...@codeaurora.org; peterpand...@micron.com; frieder.schre...@exceet.de; 
> linux-
> m...@lists.infradead.org; linux-kernel@vger.kernel.org; Michal Simek 
> ;
> nagasureshkumarre...@gmail.com
> Subject: Re: [LINUX PATCH v10 2/2] mtd: rawnand: arasan: Add support for 
> Arasan
> NAND Flash Controller
> 
> Hi Naga,
> 
> A user of Xilinx BSP reported a problem with lockdep that I can see is not 
> yet fixed in this
> code:
I didn't know this. thanks for reporting the issue. let me check.
> 
> Naga Sureshkumar Relli  wrote on Fri, 17 
> Aug 2018
> 18:49:24 +0530:
> 
> > +static int anfc_probe(struct platform_device *pdev) {
> > +   struct anfc_nand_controller *nfc;
> > +   struct anfc_nand_chip *anand_chip;
> > +   struct device_node *np = pdev->dev.of_node, *child;
> > +   struct resource *res;
> > +   int err;
> > +
> > +   nfc = devm_kzalloc(>dev, sizeof(*nfc), GFP_KERNEL);
> > +   if (!nfc)
> > +   return -ENOMEM;
> > +
> > +   init_waitqueue_head(>controller.wq);
> 
> The controller structure has a lock which is not initialized here. You should 
> not initialize the
> waitqueue manually neither and instead use 
> nand_controller_init(>controller).
Ok. Just now I saw marvell nand driver. I will update accordingly.
> 
> > +   INIT_LIST_HEAD(>chips);
> > +   init_completion(>event);
> > +   nfc->dev = >dev;
> > +   platform_set_drvdata(pdev, nfc);
> > +   nfc->csnum = -1;
> > +   nfc->controller.ops = _nand_controller_ops;
> 
> More to come.

Thanks,
Naga Sureshkumar Relli.
> 
> Thanks,
> Miquèl

RE: [LINUX PATCH v10 2/2] mtd: rawnand: arasan: Add support for Arasan NAND Flash Controller

Hi Miquel,

Thanks for the review.

> -Original Message-
> From: Miquel Raynal [mailto:miquel.ray...@bootlin.com]
> Sent: Friday, August 17, 2018 8:08 PM
> To: Naga Sureshkumar Relli 
> Cc: boris.brezil...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> computersforpe...@gmail.com; marek.va...@gmail.com; kyungmin.p...@samsung.com;
> abs...@codeaurora.org; peterpand...@micron.com; frieder.schre...@exceet.de; 
> linux-
> m...@lists.infradead.org; linux-kernel@vger.kernel.org; Michal Simek 
> ;
> nagasureshkumarre...@gmail.com
> Subject: Re: [LINUX PATCH v10 2/2] mtd: rawnand: arasan: Add support for 
> Arasan
> NAND Flash Controller
> 
> Hi Naga,
> 
> A user of Xilinx BSP reported a problem with lockdep that I can see is not 
> yet fixed in this
> code:
I didn't know this. thanks for reporting the issue. let me check.
> 
> Naga Sureshkumar Relli  wrote on Fri, 17 
> Aug 2018
> 18:49:24 +0530:
> 
> > +static int anfc_probe(struct platform_device *pdev) {
> > +   struct anfc_nand_controller *nfc;
> > +   struct anfc_nand_chip *anand_chip;
> > +   struct device_node *np = pdev->dev.of_node, *child;
> > +   struct resource *res;
> > +   int err;
> > +
> > +   nfc = devm_kzalloc(>dev, sizeof(*nfc), GFP_KERNEL);
> > +   if (!nfc)
> > +   return -ENOMEM;
> > +
> > +   init_waitqueue_head(>controller.wq);
> 
> The controller structure has a lock which is not initialized here. You should 
> not initialize the
> waitqueue manually neither and instead use 
> nand_controller_init(>controller).
Ok. Just now I saw marvell nand driver. I will update accordingly.
> 
> > +   INIT_LIST_HEAD(>chips);
> > +   init_completion(>event);
> > +   nfc->dev = >dev;
> > +   platform_set_drvdata(pdev, nfc);
> > +   nfc->csnum = -1;
> > +   nfc->controller.ops = _nand_controller_ops;
> 
> More to come.

Thanks,
Naga Sureshkumar Relli.
> 
> Thanks,
> Miquèl

Re: [RFC PATCH 2/6] pci: Set pci_dev->is_added before calling device_add

On Fri, 2018-08-17 at 20:15 +0200, Lukas Wunner wrote:
> 
> The two steps (enumeration and driver attachment) are protected by
> pci_lock_rescan_remove().  Initially, when a pci_dev is newly allocated
> with kzalloc(), is_added is 0.  The transition from 0 to 1 happens while
> under pci_lock_rescan_remove().  When that lock is released, is_added is
> always 1, barring a device_attach() error, in which case it will remain
> at 0.
> 
> AFAICS, there is no second mutex needed to ensure synchronization of
> is_added, the existing mutex should be sufficient and the only problem
> are RMW races when accessing adjacent flags. Those were correctly addressed
> by Hari's patch.  Benjamin seems to be alleging that concurrency issues
> exist beyond the RMW races, I fail to see them, sorry.

Im saying that fixing those issues using atomic bitops is a generally
unsafe practice even if it happens to work in a specific case.

In this one, I argue that the root problem was simply that is_added was
set in the wrong place. The "fix" from Hari touches 9 files, adds
horrible relative includes to an architecture and generally bloats
things while a single 3 liner would have been sufficient.

The current use of is_added is asymetric (it's cleared during
device_attach but set during detach) which is bogus and the entire race
stems from the fact that it is set after device_attach returns.

So setting it early is, imho, the right fix, is much simpler, and fixes
the odd imbalance we have to begin with.

Ben.

Re: [RFC PATCH 2/6] pci: Set pci_dev->is_added before calling device_add

On Fri, 2018-08-17 at 20:15 +0200, Lukas Wunner wrote:
> 
> The two steps (enumeration and driver attachment) are protected by
> pci_lock_rescan_remove().  Initially, when a pci_dev is newly allocated
> with kzalloc(), is_added is 0.  The transition from 0 to 1 happens while
> under pci_lock_rescan_remove().  When that lock is released, is_added is
> always 1, barring a device_attach() error, in which case it will remain
> at 0.
> 
> AFAICS, there is no second mutex needed to ensure synchronization of
> is_added, the existing mutex should be sufficient and the only problem
> are RMW races when accessing adjacent flags. Those were correctly addressed
> by Hari's patch.  Benjamin seems to be alleging that concurrency issues
> exist beyond the RMW races, I fail to see them, sorry.

Im saying that fixing those issues using atomic bitops is a generally
unsafe practice even if it happens to work in a specific case.

In this one, I argue that the root problem was simply that is_added was
set in the wrong place. The "fix" from Hari touches 9 files, adds
horrible relative includes to an architecture and generally bloats
things while a single 3 liner would have been sufficient.

The current use of is_added is asymetric (it's cleared during
device_attach but set during detach) which is bogus and the entire race
stems from the fact that it is set after device_attach returns.

So setting it early is, imho, the right fix, is much simpler, and fixes
the odd imbalance we have to begin with.

Ben.

Re: [RFC PATCH 2/6] pci: Set pci_dev->is_added before calling device_add

On Fri, 2018-08-17 at 11:25 -0500, Bjorn Helgaas wrote:
> On Fri, Aug 17, 2018 at 02:48:58PM +1000, Benjamin Herrenschmidt wrote:
> > This re-fixes the bug reported by Hari Vyas 
> > after my revert of his commit but in a much simpler way.
> > 
> > The main issues is that is_added was being set after the driver
> > got bound and started, and thus setting it could race with other
> > changes to struct pci_dev.
> 
> The "bind driver, then set dev->added = 1" order seems to have been
> there since the beginning of dev->is_added:
> 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8a1bc9013a03
> 
> This patch seems reasonable, but I'm a little dubious about the
> existence of "is_added" in the first place.  As far as I can tell, the
> only other buses with something similar are the MEN Chameleon bus and
> the Intel Management Engine Interface.
> 
> The PCI uses of "is_added" don't seem *that* critical or unique to
> PCI, so I'm not 100% convinced we need it at all.  But I haven't
> looked into it enough to be able to propose an alternative.

This is a whole different conversation you are taking us into :-)

is_added is currently needed for a number of reasons, mostly relating
to partial hotplug, and historically comes from the fact that we
separated the PCI probing & tree construction from the registration
with the device-model. This of course comes from the fact that the
device model didn't actually exist yet when the PCI code was
created :-)

So let's keep things separate shall we ? I'd rather fix this correctly
now, and get rid of that pesky atomic priv_flags which I think is just
going to be a long term add to the mess rather than an improvement, and
separately we can discuss whether is_added is something that can go
away, but I suspect this will come in the form of either a deeper
rework of how we do PCI probing, or simply finding a struct device/kobj
field we can use as a hint that we've added the device already for
hotplug.

> > This fixes it by setting the flag first, which also has the
> > advantage of matching the fact that we are clearing it *after*
> > unbinding in the remove path, thus the flag is now symtetric
> > and always set while the driver code is running.
> > 
> > Signed-off-by: Benjamin Herrenschmidt 
> > ---
> >  drivers/pci/bus.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
> > index 35b7fc87eac5..48ae63673aa8 100644
> > --- a/drivers/pci/bus.c
> > +++ b/drivers/pci/bus.c
> > @@ -321,16 +321,16 @@ void pci_bus_add_device(struct pci_dev *dev)
> > pci_proc_attach_device(dev);
> > pci_bridge_d3_update(dev);
> >  
> > +   dev->is_added = 1;
> > dev->match_driver = true;
> > retval = device_attach(>dev);
> > if (retval < 0 && retval != -EPROBE_DEFER) {
> > +   dev->is_added = 0;
> > pci_warn(dev, "device attach failed (%d)\n", retval);
> > pci_proc_detach_device(dev);
> > pci_remove_sysfs_dev_files(dev);
> > return;
> > }
> > -
> > -   dev->is_added = 1;
> >  }
> >  EXPORT_SYMBOL_GPL(pci_bus_add_device);
> >  
> > -- 
> > 2.17.1
> >

Re: [RFC PATCH 2/6] pci: Set pci_dev->is_added before calling device_add

On Fri, 2018-08-17 at 11:25 -0500, Bjorn Helgaas wrote:
> On Fri, Aug 17, 2018 at 02:48:58PM +1000, Benjamin Herrenschmidt wrote:
> > This re-fixes the bug reported by Hari Vyas 
> > after my revert of his commit but in a much simpler way.
> > 
> > The main issues is that is_added was being set after the driver
> > got bound and started, and thus setting it could race with other
> > changes to struct pci_dev.
> 
> The "bind driver, then set dev->added = 1" order seems to have been
> there since the beginning of dev->is_added:
> 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8a1bc9013a03
> 
> This patch seems reasonable, but I'm a little dubious about the
> existence of "is_added" in the first place.  As far as I can tell, the
> only other buses with something similar are the MEN Chameleon bus and
> the Intel Management Engine Interface.
> 
> The PCI uses of "is_added" don't seem *that* critical or unique to
> PCI, so I'm not 100% convinced we need it at all.  But I haven't
> looked into it enough to be able to propose an alternative.

This is a whole different conversation you are taking us into :-)

is_added is currently needed for a number of reasons, mostly relating
to partial hotplug, and historically comes from the fact that we
separated the PCI probing & tree construction from the registration
with the device-model. This of course comes from the fact that the
device model didn't actually exist yet when the PCI code was
created :-)

So let's keep things separate shall we ? I'd rather fix this correctly
now, and get rid of that pesky atomic priv_flags which I think is just
going to be a long term add to the mess rather than an improvement, and
separately we can discuss whether is_added is something that can go
away, but I suspect this will come in the form of either a deeper
rework of how we do PCI probing, or simply finding a struct device/kobj
field we can use as a hint that we've added the device already for
hotplug.

> > This fixes it by setting the flag first, which also has the
> > advantage of matching the fact that we are clearing it *after*
> > unbinding in the remove path, thus the flag is now symtetric
> > and always set while the driver code is running.
> > 
> > Signed-off-by: Benjamin Herrenschmidt 
> > ---
> >  drivers/pci/bus.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
> > index 35b7fc87eac5..48ae63673aa8 100644
> > --- a/drivers/pci/bus.c
> > +++ b/drivers/pci/bus.c
> > @@ -321,16 +321,16 @@ void pci_bus_add_device(struct pci_dev *dev)
> > pci_proc_attach_device(dev);
> > pci_bridge_d3_update(dev);
> >  
> > +   dev->is_added = 1;
> > dev->match_driver = true;
> > retval = device_attach(>dev);
> > if (retval < 0 && retval != -EPROBE_DEFER) {
> > +   dev->is_added = 0;
> > pci_warn(dev, "device attach failed (%d)\n", retval);
> > pci_proc_detach_device(dev);
> > pci_remove_sysfs_dev_files(dev);
> > return;
> > }
> > -
> > -   dev->is_added = 1;
> >  }
> >  EXPORT_SYMBOL_GPL(pci_bus_add_device);
> >  
> > -- 
> > 2.17.1
> >

Re: [RFC PATCH 1/6] Revert "PCI: Fix is_added/is_busmaster race condition"

On Fri, 2018-08-17 at 10:44 -0500, Bjorn Helgaas wrote:
> On Fri, Aug 17, 2018 at 02:48:57PM +1000, Benjamin Herrenschmidt wrote:
> > This reverts commit 44bda4b7d26e9fffed6d7152d98a2e9edaeb2a76.
> 
> Just to be clear, if I understand correctly, this is a pure revert of
> 44bda4b7d26e and as such it reintroduces the problem solved by that
> commit.
> 
> If your solution turns out to be better, that's great, but it would be
> nice to avoid the bisection hole of reintroducing the problem, then
> fixing it again later.

There is no way to do that other than merging the revert and the fix
into one. That said, the race is sufficiently hard to hit that I
wouldn't worry too much about it.

> > The new pci state mutex provides a simpler way of addressing
> > this race and avoids the relative includes added to the powerpc
> > code.

Re: [RFC PATCH 1/6] Revert "PCI: Fix is_added/is_busmaster race condition"

On Fri, 2018-08-17 at 10:44 -0500, Bjorn Helgaas wrote:
> On Fri, Aug 17, 2018 at 02:48:57PM +1000, Benjamin Herrenschmidt wrote:
> > This reverts commit 44bda4b7d26e9fffed6d7152d98a2e9edaeb2a76.
> 
> Just to be clear, if I understand correctly, this is a pure revert of
> 44bda4b7d26e and as such it reintroduces the problem solved by that
> commit.
> 
> If your solution turns out to be better, that's great, but it would be
> nice to avoid the bisection hole of reintroducing the problem, then
> fixing it again later.

There is no way to do that other than merging the revert and the fix
into one. That said, the race is sufficiently hard to hit that I
wouldn't worry too much about it.

> > The new pci state mutex provides a simpler way of addressing
> > this race and avoids the relative includes added to the powerpc
> > code.

Re: Crash in MM code in v4.4.y, v4.9.y with TRANSPARENT_HUGEPAGE enabled

> Plus I'd have expected the problem to have been in mainline too, and
> apparently it's just the 4.4 and 4.9 backports.

There's another problem in 4.17, but not 4.18, see 
https://bugzilla.redhat.com/show_bug.cgi?id=1618792

Could be the same or different.

-Andi

> 
> Your test-case does have mprotect with PROT_NONE. Which together with
> that mask that *might* be PHYSICAL_PMD_PAGE_MASK makes me think it
> might be related.
> 
>  Linus

Re: Crash in MM code in v4.4.y, v4.9.y with TRANSPARENT_HUGEPAGE enabled

> Plus I'd have expected the problem to have been in mainline too, and
> apparently it's just the 4.4 and 4.9 backports.

There's another problem in 4.17, but not 4.18, see 
https://bugzilla.redhat.com/show_bug.cgi?id=1618792

Could be the same or different.

-Andi

> 
> Your test-case does have mprotect with PROT_NONE. Which together with
> that mask that *might* be PHYSICAL_PMD_PAGE_MASK makes me think it
> might be related.
> 
>  Linus

[PATCH] Revert "Permit silencing of __deprecated warnings."

This reverts commit de48844398f81cfdf087d56e12c920d620dae8d5.

Linus would prefer that __deprecated never produce a warning in an
allyesconfig compile. Since we have been at this state for some time,
the option no longer has a purpose.

Link: 
https://lkml.kernel.org/r/ca+55afyglkszs8o3m4jae69wum03tgof+507jccvitrqagb...@mail.gmail.com
Signed-off-by: Jason Gunthorpe 
---
 Documentation/process/4.Coding.rst | 2 +-
 include/linux/compiler_types.h | 6 --
 lib/Kconfig.debug  | 8 
 3 files changed, 1 insertion(+), 15 deletions(-)

Linus: As discussed.

Jonathan: I'm not sure if you prefer diffs to documentation to be
minimal like this, or if should reflow the paragraph?

I can send this in a PR via rdma.git with the __deprecation removal
patch probably Monday/Tuesday if there is agreement, no 0-day
surprises, etc.

Cheers,
Jason

diff --git a/Documentation/process/4.Coding.rst 
b/Documentation/process/4.Coding.rst
index eb4b185d168c05..f03c62f50d7d0a 100644
--- a/Documentation/process/4.Coding.rst
+++ b/Documentation/process/4.Coding.rst
@@ -249,7 +249,7 @@ features; most of these are found in the "kernel hacking" 
submenu.  Several
 of these options should be turned on for any kernel used for development or
 testing purposes.  In particular, you should turn on:
 
- - ENABLE_WARN_DEPRECATED, ENABLE_MUST_CHECK, and FRAME_WARN to get an
+ - ENABLE_MUST_CHECK, and FRAME_WARN to get an
extra set of warnings for problems like the use of deprecated interfaces
or ignoring an important return value from a function.  The output
generated by these warnings can be verbose, but one need not worry about
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index a8ba6b04152c13..a2b428c43ae134 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -135,12 +135,6 @@ struct ftrace_likely_data {
 #undef __must_check
 #define __must_check
 #endif
-#ifndef CONFIG_ENABLE_WARN_DEPRECATED
-#undef __deprecated
-#undef __deprecated_for_modules
-#define __deprecated
-#define __deprecated_for_modules
-#endif
 
 #ifndef __malloc
 #define __malloc
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c6e73904c5a5da..ab1b599202bca7 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -211,14 +211,6 @@ config GDB_SCRIPTS
  instance. See Documentation/dev-tools/gdb-kernel-debugging.rst
  for further details.
 
-config ENABLE_WARN_DEPRECATED
-   bool "Enable __deprecated logic"
-   default y
-   help
- Enable the __deprecated logic in the kernel build.
- Disable this to suppress the "warning: 'foo' is deprecated
- (declared at kernel/power/somefile.c:1234)" messages.
-
 config ENABLE_MUST_CHECK
bool "Enable __must_check logic"
default y
-- 
2.18.0

[PATCH] Revert "Permit silencing of __deprecated warnings."

This reverts commit de48844398f81cfdf087d56e12c920d620dae8d5.

Linus would prefer that __deprecated never produce a warning in an
allyesconfig compile. Since we have been at this state for some time,
the option no longer has a purpose.

Link: 
https://lkml.kernel.org/r/ca+55afyglkszs8o3m4jae69wum03tgof+507jccvitrqagb...@mail.gmail.com
Signed-off-by: Jason Gunthorpe 
---
 Documentation/process/4.Coding.rst | 2 +-
 include/linux/compiler_types.h | 6 --
 lib/Kconfig.debug  | 8 
 3 files changed, 1 insertion(+), 15 deletions(-)

Linus: As discussed.

Jonathan: I'm not sure if you prefer diffs to documentation to be
minimal like this, or if should reflow the paragraph?

I can send this in a PR via rdma.git with the __deprecation removal
patch probably Monday/Tuesday if there is agreement, no 0-day
surprises, etc.

Cheers,
Jason

diff --git a/Documentation/process/4.Coding.rst 
b/Documentation/process/4.Coding.rst
index eb4b185d168c05..f03c62f50d7d0a 100644
--- a/Documentation/process/4.Coding.rst
+++ b/Documentation/process/4.Coding.rst
@@ -249,7 +249,7 @@ features; most of these are found in the "kernel hacking" 
submenu.  Several
 of these options should be turned on for any kernel used for development or
 testing purposes.  In particular, you should turn on:
 
- - ENABLE_WARN_DEPRECATED, ENABLE_MUST_CHECK, and FRAME_WARN to get an
+ - ENABLE_MUST_CHECK, and FRAME_WARN to get an
extra set of warnings for problems like the use of deprecated interfaces
or ignoring an important return value from a function.  The output
generated by these warnings can be verbose, but one need not worry about
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index a8ba6b04152c13..a2b428c43ae134 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -135,12 +135,6 @@ struct ftrace_likely_data {
 #undef __must_check
 #define __must_check
 #endif
-#ifndef CONFIG_ENABLE_WARN_DEPRECATED
-#undef __deprecated
-#undef __deprecated_for_modules
-#define __deprecated
-#define __deprecated_for_modules
-#endif
 
 #ifndef __malloc
 #define __malloc
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c6e73904c5a5da..ab1b599202bca7 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -211,14 +211,6 @@ config GDB_SCRIPTS
  instance. See Documentation/dev-tools/gdb-kernel-debugging.rst
  for further details.
 
-config ENABLE_WARN_DEPRECATED
-   bool "Enable __deprecated logic"
-   default y
-   help
- Enable the __deprecated logic in the kernel build.
- Disable this to suppress the "warning: 'foo' is deprecated
- (declared at kernel/power/somefile.c:1234)" messages.
-
 config ENABLE_MUST_CHECK
bool "Enable __must_check logic"
default y
-- 
2.18.0

Re: [PATCH v4 0/2] clk: qcom: Add support for RCG to register for DFS

2018-08-17 Thread Stephen Boyd

Quoting Taniya Das (2018-08-10 18:53:54)
>  [v4]
>   * Add recalc_clk_ops to calculate the clock frequency reading the current
> perf state, also add CLK_GET_RATE_NOCACHE flag.
>   * Cleanup 'goto' during mode check in 'clk_rcg2_calculate_freq'.
>   * cleanup return from function 'com_cc_register_rcg_dfs'.

I want to squash this in. I have only compile tested it. Let me know
what you think.

8<---
diff --git a/drivers/clk/qcom/clk-rcg.h b/drivers/clk/qcom/clk-rcg.h
index e6300e05d5df..e5eca8a1abe4 100644
--- a/drivers/clk/qcom/clk-rcg.h
+++ b/drivers/clk/qcom/clk-rcg.h
@@ -163,6 +163,15 @@ extern const struct clk_ops clk_pixel_ops;
 extern const struct clk_ops clk_gfx3d_ops;
 extern const struct clk_ops clk_rcg2_shared_ops;
 
+struct clk_rcg_dfs_data {
+   struct clk_rcg2 *rcg;
+   struct clk_init_data *init;
+};
+
+#define DEFINE_RCG_DFS(r) \
+   { .rcg = ##_src, .init = ##_init }
+
 extern int qcom_cc_register_rcg_dfs(struct regmap *regmap,
-struct clk_rcg2 **rcgs, int num_clks);
+   const struct clk_rcg_dfs_data *rcgs,
+   size_t len);
 #endif
diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
index 55a5b58cbb15..bbe2a1916296 100644
--- a/drivers/clk/qcom/clk-rcg2.c
+++ b/drivers/clk/qcom/clk-rcg2.c
@@ -1051,48 +1051,24 @@ static unsigned long
 clk_rcg2_dfs_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
 {
struct clk_rcg2 *rcg = to_clk_rcg2(hw);
-   u32 cfg, hid_div, m = 0, n = 0, mode = 0, mask, level;
-   int num_parents, i;
-   unsigned long prate;
-
-   regmap_read(rcg->clkr.regmap, rcg->cmd_rcgr +
-   SE_CMD_DFSR_OFFSET, );
-   level = (GENMASK(4, 1) & cfg) >> 1;
-
-   regmap_read(rcg->clkr.regmap, rcg->cmd_rcgr +
-   SE_PERF_DFSR(level), );
-   if (rcg->mnd_width) {
-   mask = BIT(rcg->mnd_width) - 1;
-   regmap_read(rcg->clkr.regmap, rcg->cmd_rcgr +
-   SE_PERF_M_DFSR(level), );
-   m &= mask;
-   regmap_read(rcg->clkr.regmap, rcg->cmd_rcgr +
-   SE_PERF_N_DFSR(level), );
-   n =  ~n;
-   n &= mask;
-   n += m;
-   mode = cfg & CFG_MODE_MASK;
-   mode >>= CFG_MODE_SHIFT;
-   }
+   int ret;
+   u32 level;
 
-   mask = BIT(rcg->hid_width) - 1;
-   hid_div = cfg >> CFG_SRC_DIV_SHIFT;
-   hid_div &= mask;
-   cfg &= CFG_SRC_SEL_MASK;
-   cfg >>= CFG_SRC_SEL_SHIFT;
+   regmap_read(rcg->clkr.regmap,
+   rcg->cmd_rcgr + SE_CMD_DFSR_OFFSET, );
+   level &= GENMASK(4, 1);
+   level >>= 1;
 
-   num_parents = clk_hw_get_num_parents(hw);
-   for (i = 0; i < num_parents; i++) {
-   if (cfg == rcg->parent_map[i].cfg) {
-   prate = clk_hw_get_rate(
-   clk_hw_get_parent_by_index(>clkr.hw, i));
-   if (parent_rate != prate)
-   parent_rate = prate;
+   if (!rcg->freq_tbl) {
+   ret = clk_rcg2_dfs_populate_freq_table(rcg);
+   if (ret) {
+   pr_err("Failed to update DFS tables for %s\n",
+   clk_hw_get_name(hw));
+   return ret;
}
}
 
-
-   return calc_rate(parent_rate, m, n, mode, hid_div);
+   return rcg->freq_tbl[level].freq;
 }
 
 static const struct clk_ops clk_rcg2_dfs_ops = {
@@ -1102,9 +1078,11 @@ static const struct clk_ops clk_rcg2_dfs_ops = {
.recalc_rate = clk_rcg2_dfs_recalc_rate,
 };
 
-static int clk_rcg2_enable_dfs(struct clk_rcg2 *rcg, struct regmap *regmap)
+static int clk_rcg2_enable_dfs(const struct clk_rcg_dfs_data *data,
+  struct regmap *regmap)
 {
-   struct clk_init_data *init;
+   struct clk_rcg2 *rcg = data->rcg;
+   struct clk_init_data *init = data->init;
u32 val;
int ret;
 
@@ -1116,18 +1094,13 @@ static int clk_rcg2_enable_dfs(struct clk_rcg2 *rcg, 
struct regmap *regmap)
if (!(val & SE_CMD_DFS_EN))
return 0;
 
-   init = kzalloc(sizeof(*init), GFP_KERNEL);
-   if (!init)
-   return -ENOMEM;
-
-   init->name = rcg->clkr.hw.init->name;
-   init->flags = rcg->clkr.hw.init->flags;
-   init->parent_names = rcg->clkr.hw.init->parent_names;
-   init->num_parents = rcg->clkr.hw.init->num_parents;
-   init->flags = CLK_GET_RATE_NOCACHE;
+   /*
+* Rate changes with consumer writing a register in
+* their own I/O region
+*/
+   init->flags |= CLK_GET_RATE_NOCACHE;
init->ops = _rcg2_dfs_ops;
 
-   rcg->clkr.hw.init = init;
rcg->freq_tbl = NULL;
 
pr_debug("DFS registered for clk %s\n", init->name);
@@ -1136,14

Re: [PATCH v4 0/2] clk: qcom: Add support for RCG to register for DFS

2018-08-17 Thread Stephen Boyd

Quoting Taniya Das (2018-08-10 18:53:54)
>  [v4]
>   * Add recalc_clk_ops to calculate the clock frequency reading the current
> perf state, also add CLK_GET_RATE_NOCACHE flag.
>   * Cleanup 'goto' during mode check in 'clk_rcg2_calculate_freq'.
>   * cleanup return from function 'com_cc_register_rcg_dfs'.

I want to squash this in. I have only compile tested it. Let me know
what you think.

8<---
diff --git a/drivers/clk/qcom/clk-rcg.h b/drivers/clk/qcom/clk-rcg.h
index e6300e05d5df..e5eca8a1abe4 100644
--- a/drivers/clk/qcom/clk-rcg.h
+++ b/drivers/clk/qcom/clk-rcg.h
@@ -163,6 +163,15 @@ extern const struct clk_ops clk_pixel_ops;
 extern const struct clk_ops clk_gfx3d_ops;
 extern const struct clk_ops clk_rcg2_shared_ops;
 
+struct clk_rcg_dfs_data {
+   struct clk_rcg2 *rcg;
+   struct clk_init_data *init;
+};
+
+#define DEFINE_RCG_DFS(r) \
+   { .rcg = ##_src, .init = ##_init }
+
 extern int qcom_cc_register_rcg_dfs(struct regmap *regmap,
-struct clk_rcg2 **rcgs, int num_clks);
+   const struct clk_rcg_dfs_data *rcgs,
+   size_t len);
 #endif
diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
index 55a5b58cbb15..bbe2a1916296 100644
--- a/drivers/clk/qcom/clk-rcg2.c
+++ b/drivers/clk/qcom/clk-rcg2.c
@@ -1051,48 +1051,24 @@ static unsigned long
 clk_rcg2_dfs_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
 {
struct clk_rcg2 *rcg = to_clk_rcg2(hw);
-   u32 cfg, hid_div, m = 0, n = 0, mode = 0, mask, level;
-   int num_parents, i;
-   unsigned long prate;
-
-   regmap_read(rcg->clkr.regmap, rcg->cmd_rcgr +
-   SE_CMD_DFSR_OFFSET, );
-   level = (GENMASK(4, 1) & cfg) >> 1;
-
-   regmap_read(rcg->clkr.regmap, rcg->cmd_rcgr +
-   SE_PERF_DFSR(level), );
-   if (rcg->mnd_width) {
-   mask = BIT(rcg->mnd_width) - 1;
-   regmap_read(rcg->clkr.regmap, rcg->cmd_rcgr +
-   SE_PERF_M_DFSR(level), );
-   m &= mask;
-   regmap_read(rcg->clkr.regmap, rcg->cmd_rcgr +
-   SE_PERF_N_DFSR(level), );
-   n =  ~n;
-   n &= mask;
-   n += m;
-   mode = cfg & CFG_MODE_MASK;
-   mode >>= CFG_MODE_SHIFT;
-   }
+   int ret;
+   u32 level;
 
-   mask = BIT(rcg->hid_width) - 1;
-   hid_div = cfg >> CFG_SRC_DIV_SHIFT;
-   hid_div &= mask;
-   cfg &= CFG_SRC_SEL_MASK;
-   cfg >>= CFG_SRC_SEL_SHIFT;
+   regmap_read(rcg->clkr.regmap,
+   rcg->cmd_rcgr + SE_CMD_DFSR_OFFSET, );
+   level &= GENMASK(4, 1);
+   level >>= 1;
 
-   num_parents = clk_hw_get_num_parents(hw);
-   for (i = 0; i < num_parents; i++) {
-   if (cfg == rcg->parent_map[i].cfg) {
-   prate = clk_hw_get_rate(
-   clk_hw_get_parent_by_index(>clkr.hw, i));
-   if (parent_rate != prate)
-   parent_rate = prate;
+   if (!rcg->freq_tbl) {
+   ret = clk_rcg2_dfs_populate_freq_table(rcg);
+   if (ret) {
+   pr_err("Failed to update DFS tables for %s\n",
+   clk_hw_get_name(hw));
+   return ret;
}
}
 
-
-   return calc_rate(parent_rate, m, n, mode, hid_div);
+   return rcg->freq_tbl[level].freq;
 }
 
 static const struct clk_ops clk_rcg2_dfs_ops = {
@@ -1102,9 +1078,11 @@ static const struct clk_ops clk_rcg2_dfs_ops = {
.recalc_rate = clk_rcg2_dfs_recalc_rate,
 };
 
-static int clk_rcg2_enable_dfs(struct clk_rcg2 *rcg, struct regmap *regmap)
+static int clk_rcg2_enable_dfs(const struct clk_rcg_dfs_data *data,
+  struct regmap *regmap)
 {
-   struct clk_init_data *init;
+   struct clk_rcg2 *rcg = data->rcg;
+   struct clk_init_data *init = data->init;
u32 val;
int ret;
 
@@ -1116,18 +1094,13 @@ static int clk_rcg2_enable_dfs(struct clk_rcg2 *rcg, 
struct regmap *regmap)
if (!(val & SE_CMD_DFS_EN))
return 0;
 
-   init = kzalloc(sizeof(*init), GFP_KERNEL);
-   if (!init)
-   return -ENOMEM;
-
-   init->name = rcg->clkr.hw.init->name;
-   init->flags = rcg->clkr.hw.init->flags;
-   init->parent_names = rcg->clkr.hw.init->parent_names;
-   init->num_parents = rcg->clkr.hw.init->num_parents;
-   init->flags = CLK_GET_RATE_NOCACHE;
+   /*
+* Rate changes with consumer writing a register in
+* their own I/O region
+*/
+   init->flags |= CLK_GET_RATE_NOCACHE;
init->ops = _rcg2_dfs_ops;
 
-   rcg->clkr.hw.init = init;
rcg->freq_tbl = NULL;
 
pr_debug("DFS registered for clk %s\n", init->name);
@@ -1136,14

Re: [RFC PATCH 3/5] RISC-V: Add cpu_operatios structure

2018-08-17 Thread Atish Patra


On 8/15/18 11:21 PM, Anup Patel wrote:

On Thu, Aug 16, 2018 at 11:10 AM, Atish Patra  wrote:

On 8/15/18 10:02 PM, Anup Patel wrote:


On Thu, Aug 16, 2018 at 5:26 AM, Atish Patra  wrote:


Defining cpu_operations now helps adding cpu hotplug
support in proper manner. Moreover, it provides flexibility
in supporting other cpu enable/boot methods can be
supported in future. This patch has been largely inspired from
ARM64. However, a default boot method is defined for RISC-V unlike
ARM64.

Signed-off-by: Atish Patra 
---
   arch/riscv/include/asm/smp.h | 10 ++
   arch/riscv/kernel/smp.c  |  8 
   arch/riscv/kernel/smpboot.c  | 34 --
   3 files changed, 46 insertions(+), 6 deletions(-)

diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
index 0763337b..2bb6e6c2 100644
--- a/arch/riscv/include/asm/smp.h
+++ b/arch/riscv/include/asm/smp.h
@@ -28,6 +28,15 @@
   extern u64 __cpu_logical_map[NR_CPUS];
   #define cpu_logical_map(cpu)__cpu_logical_map[cpu]

+struct cpu_operations {
+   const char  *name;
+   int (*cpu_init)(unsigned int);
+   int (*cpu_prepare)(unsigned int);
+   int (*cpu_boot)(unsigned int, struct task_struct *);
+};
+extern struct cpu_operations cpu_ops;
+void smp_set_cpu_ops(const struct cpu_operations *cpu_ops);
+
   #ifdef CONFIG_SMP

   /* SMP initialization hook for setup_arch */
@@ -57,5 +66,6 @@ static inline void cpuid_to_hartid_mask(const struct
cpumask *in,
  cpumask_set_cpu(cpu_logical_map(0), out);
   }

+
   #endif /* CONFIG_SMP */
   #endif /* _ASM_RISCV_SMP_H */
diff --git a/arch/riscv/kernel/smp.c b/arch/riscv/kernel/smp.c
index 4ab70480..5de58ced 100644
--- a/arch/riscv/kernel/smp.c
+++ b/arch/riscv/kernel/smp.c
@@ -58,6 +58,14 @@ void cpuid_to_hartid_mask(const struct cpumask *in,
struct cpumask *out)
  for_each_cpu(cpu, in)
  cpumask_set_cpu(cpu_logical_map(cpu), out);
   }
+struct cpu_operations cpu_ops __ro_after_init;
+
+void smp_set_cpu_ops(const struct cpu_operations *ops)
+{
+   if (ops)
+   cpu_ops = *ops;
+}
+



Move both cpu_ops and smp_set_cpu_ops() to smpboot.c. This way
you will not require to make cpu_ops as global.


ok.


Further, I think cpu_ops should be a pointer and initial value should
be _ops.

Something like this:
struct cpu_operations *cpu_ops __ro_after_init = _ops;



That will work too. However, setting it through smp_set_cpu_ops provides a
sample implementation for any future SMP enable methods. That's why I used
the API. I can change it if you think otherwise.


Having thought about this more, I think cpu_ops should be an pointer array
of NR_CPUS size. This means its not necessary to have have same ops for
all CPUs. The ARM64 implementation of CPU operations also allows separate
CPU operations for each CPU.



I initially had NR_CPUs based pointer array implementation similar to 
arm64. However, I couldn't find a use case for it. So I removed it.




For example, let's us assume that we have an SOC where we 2 cores
per-cluster and N clusters. All CPUs of cluster0 comes up at the same time
whereas cluster1 onwards we have to bring-up CPUs using special HW
mechanism.



I was not aware of such a use case. If that's a valid possible future 
use case, we should make it pointer array implementation. I will add it 
in v2


Regards,
Atish





   /* Unsupported */
   int setup_profiling_timer(unsigned int multiplier)
   {
diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
index 6ab2bb1b..045a1a45 100644
--- a/arch/riscv/kernel/smpboot.c
+++ b/arch/riscv/kernel/smpboot.c
@@ -30,6 +30,7 @@
   #include 
   #include 
   #include 
+#include 
   #include 
   #include 
   #include 
@@ -38,6 +39,7 @@

   void *__cpu_up_stack_pointer[NR_CPUS];
   void *__cpu_up_task_pointer[NR_CPUS];
+struct cpu_operations default_ops;

   void __init smp_prepare_boot_cpu(void)
   {
@@ -53,6 +55,7 @@ void __init setup_smp(void)
  int hart, found_boot_cpu = 0;
  int cpuid = 1;

+   smp_set_cpu_ops(_ops);
  while ((dn = of_find_node_by_type(dn, "cpu"))) {
  hart = riscv_of_processor_hart(dn);

@@ -73,10 +76,8 @@ void __init setup_smp(void)
  BUG_ON(!found_boot_cpu);
   }

-int __cpu_up(unsigned int cpu, struct task_struct *tidle)
+int default_cpu_boot(unsigned int hartid, struct task_struct *tidle)
   {
-   int hartid = cpu_logical_map(cpu);
-   tidle->thread_info.cpu = cpu;
  /*
   * On RISC-V systems, all harts boot on their own accord.  Our
_start
   * selects the first hart to boot the kernel and causes the
remainder
@@ -84,13 +85,28 @@ int __cpu_up(unsigned int cpu, struct task_struct
*tidle)
   * setup by that main hart.  Writing __cpu_up_stack_pointer
signals to
   * the spinning harts that they can continue the boot process.
   */
-   smp_mb();
+

Re: [RFC PATCH 3/5] RISC-V: Add cpu_operatios structure

2018-08-17 Thread Atish Patra


On 8/15/18 11:21 PM, Anup Patel wrote:

On Thu, Aug 16, 2018 at 11:10 AM, Atish Patra  wrote:

On 8/15/18 10:02 PM, Anup Patel wrote:


On Thu, Aug 16, 2018 at 5:26 AM, Atish Patra  wrote:


Defining cpu_operations now helps adding cpu hotplug
support in proper manner. Moreover, it provides flexibility
in supporting other cpu enable/boot methods can be
supported in future. This patch has been largely inspired from
ARM64. However, a default boot method is defined for RISC-V unlike
ARM64.

Signed-off-by: Atish Patra 
---
   arch/riscv/include/asm/smp.h | 10 ++
   arch/riscv/kernel/smp.c  |  8 
   arch/riscv/kernel/smpboot.c  | 34 --
   3 files changed, 46 insertions(+), 6 deletions(-)

diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
index 0763337b..2bb6e6c2 100644
--- a/arch/riscv/include/asm/smp.h
+++ b/arch/riscv/include/asm/smp.h
@@ -28,6 +28,15 @@
   extern u64 __cpu_logical_map[NR_CPUS];
   #define cpu_logical_map(cpu)__cpu_logical_map[cpu]

+struct cpu_operations {
+   const char  *name;
+   int (*cpu_init)(unsigned int);
+   int (*cpu_prepare)(unsigned int);
+   int (*cpu_boot)(unsigned int, struct task_struct *);
+};
+extern struct cpu_operations cpu_ops;
+void smp_set_cpu_ops(const struct cpu_operations *cpu_ops);
+
   #ifdef CONFIG_SMP

   /* SMP initialization hook for setup_arch */
@@ -57,5 +66,6 @@ static inline void cpuid_to_hartid_mask(const struct
cpumask *in,
  cpumask_set_cpu(cpu_logical_map(0), out);
   }

+
   #endif /* CONFIG_SMP */
   #endif /* _ASM_RISCV_SMP_H */
diff --git a/arch/riscv/kernel/smp.c b/arch/riscv/kernel/smp.c
index 4ab70480..5de58ced 100644
--- a/arch/riscv/kernel/smp.c
+++ b/arch/riscv/kernel/smp.c
@@ -58,6 +58,14 @@ void cpuid_to_hartid_mask(const struct cpumask *in,
struct cpumask *out)
  for_each_cpu(cpu, in)
  cpumask_set_cpu(cpu_logical_map(cpu), out);
   }
+struct cpu_operations cpu_ops __ro_after_init;
+
+void smp_set_cpu_ops(const struct cpu_operations *ops)
+{
+   if (ops)
+   cpu_ops = *ops;
+}
+



Move both cpu_ops and smp_set_cpu_ops() to smpboot.c. This way
you will not require to make cpu_ops as global.


ok.


Further, I think cpu_ops should be a pointer and initial value should
be _ops.

Something like this:
struct cpu_operations *cpu_ops __ro_after_init = _ops;



That will work too. However, setting it through smp_set_cpu_ops provides a
sample implementation for any future SMP enable methods. That's why I used
the API. I can change it if you think otherwise.


Having thought about this more, I think cpu_ops should be an pointer array
of NR_CPUS size. This means its not necessary to have have same ops for
all CPUs. The ARM64 implementation of CPU operations also allows separate
CPU operations for each CPU.



I initially had NR_CPUs based pointer array implementation similar to 
arm64. However, I couldn't find a use case for it. So I removed it.




For example, let's us assume that we have an SOC where we 2 cores
per-cluster and N clusters. All CPUs of cluster0 comes up at the same time
whereas cluster1 onwards we have to bring-up CPUs using special HW
mechanism.



I was not aware of such a use case. If that's a valid possible future 
use case, we should make it pointer array implementation. I will add it 
in v2


Regards,
Atish





   /* Unsupported */
   int setup_profiling_timer(unsigned int multiplier)
   {
diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
index 6ab2bb1b..045a1a45 100644
--- a/arch/riscv/kernel/smpboot.c
+++ b/arch/riscv/kernel/smpboot.c
@@ -30,6 +30,7 @@
   #include 
   #include 
   #include 
+#include 
   #include 
   #include 
   #include 
@@ -38,6 +39,7 @@

   void *__cpu_up_stack_pointer[NR_CPUS];
   void *__cpu_up_task_pointer[NR_CPUS];
+struct cpu_operations default_ops;

   void __init smp_prepare_boot_cpu(void)
   {
@@ -53,6 +55,7 @@ void __init setup_smp(void)
  int hart, found_boot_cpu = 0;
  int cpuid = 1;

+   smp_set_cpu_ops(_ops);
  while ((dn = of_find_node_by_type(dn, "cpu"))) {
  hart = riscv_of_processor_hart(dn);

@@ -73,10 +76,8 @@ void __init setup_smp(void)
  BUG_ON(!found_boot_cpu);
   }

-int __cpu_up(unsigned int cpu, struct task_struct *tidle)
+int default_cpu_boot(unsigned int hartid, struct task_struct *tidle)
   {
-   int hartid = cpu_logical_map(cpu);
-   tidle->thread_info.cpu = cpu;
  /*
   * On RISC-V systems, all harts boot on their own accord.  Our
_start
   * selects the first hart to boot the kernel and causes the
remainder
@@ -84,13 +85,28 @@ int __cpu_up(unsigned int cpu, struct task_struct
*tidle)
   * setup by that main hart.  Writing __cpu_up_stack_pointer
signals to
   * the spinning harts that they can continue the boot process.
   */
-   smp_mb();
+

Re: [PATCH RFC] mm: don't miss the last page because of round-off error

2018-08-17 Thread Matthew Wilcox

On Fri, Aug 17, 2018 at 04:18:34PM -0700, Roman Gushchin wrote:
> - scan = div64_u64(scan * fraction[file],
> -  denominator);
> + if (scan > 1)
> + scan = div64_u64(scan * fraction[file],
> +  denominator);

Wouldn't we be better off doing a div_round_up?  ie:

scan = div64_u64(scan * fraction[file] + denominator - 1, denominator);

although i'd rather hide that in a new macro in math64.h than opencode it
here.

Re: [PATCH RFC] mm: don't miss the last page because of round-off error

2018-08-17 Thread Matthew Wilcox

On Fri, Aug 17, 2018 at 04:18:34PM -0700, Roman Gushchin wrote:
> - scan = div64_u64(scan * fraction[file],
> -  denominator);
> + if (scan > 1)
> + scan = div64_u64(scan * fraction[file],
> +  denominator);

Wouldn't we be better off doing a div_round_up?  ie:

scan = div64_u64(scan * fraction[file] + denominator - 1, denominator);

although i'd rather hide that in a new macro in math64.h than opencode it
here.

[git pull] Input updates for v4.19-rc0

2018-08-17 Thread Dmitry Torokhov

Hi Linus,

Please pull from:

git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus

to receive updates for the input subsystem. You will get:

- a new driver for Rohm BU21029 touch controller

- new bitmap APIs: bitmap_alloc, bitmap_zalloc and bitmap_free

- updates to Atmel, eeti. pxrc and iforce drivers

- assorted driver cleanups and fixes.

Changelog:
-

Andy Shevchenko (5):
  dm: Avoid namespace collision with bitmap API
  md: Avoid namespace collision with bitmap API
  bitmap: Add bitmap_alloc(), bitmap_zalloc() and bitmap_free()
  Input: gpio-keys - switch to bitmap_zalloc()
  Input: evdev - switch to bitmap API

Chen Zhong (1):
  dt-bindings: input: add common keyboard document bindings

Colin Ian King (1):
  Input: cros_ec_keyb - remove redundant variable num_cols

Daniel Mack (4):
  dt-bindings: input: touchscreen: add bindings for eeti touchscreen 
controller
  Input: eeti - add device tree matching table
  Input: eeti - drop module parameters, parse DT properties
  Input: eeti - fix link to documentation and email address in header

Dmitry Torokhov (6):
  Input: pxrc - fix freeing URB on device teardown
  Input: pxrc - move module device table closer to where it is used
  Input: pxrc - do not store unneeded data in driver structure
  Input: pxrc - flatten probe code
  Input: stop telling users to snail-mail Vojtech
  Input: do not use WARN() in input_alloc_absinfo()

Enric Balletbo i Serra (2):
  Input: cros_ec_keyb - make license text and MODULE_LICENSE match
  Input: cros_ec_keyb - switch to SPDX identifier

Fabio Estevam (5):
  Input: imx_keypad - switch to SPDX identifier
  Input: snvs_pwrkey - switch to SPDX identifier
  Input: fsl-imx25-tcq - switch to SPDX identifier
  Input: imx6ul_tsc - switch to SPDX identifier
  Input: egalax_ts - switch to SPDX identifier

Gustavo A. R. Silva (2):
  Input: raydium_i2c_ts - use true and false for boolean values
  Input: mark expected switch fall-throughs

Jia-Ju Bai (6):
  Input: wdt87xx_i2c - replace mdelay() with msleep() in wdt87xx_resume()
  Input: keyspan_remote - replace GFP_ATOMIC with GFP_KERNEL in 
keyspan_probe()
  Input: powermate - replace GFP_ATOMIC with GFP_KERNEL in 
powermate_alloc_buffers()
  Input: yealink - replace GFP_ATOMIC with GFP_KERNEL in usb_probe()
  Input: appletouch - replace GFP_ATOMIC with GFP_KERNEL
  Input: aiptek - replace GFP_ATOMIC with GFP_KERNEL in aiptek_probe()

Julia Lawall (1):
  Input: elan_i2c_smbus - cast sizeof to int for comparison

Marcus Folkesson (2):
  Input: pxrc - do not store USB device in private struct
  MAINTAINERS: Add PhoenixRC Flight Controller Adapter

Matti Vaittinen (1):
  Input: gpio_keys - add missing include to gpio_keys.h

Nick Dyer (9):
  Input: atmel_mxt_ts - only use first T9 instance
  Input: atmel_mxt_ts - use BIT() macro everywhere
  Input: atmel_mxt_ts - remove duplicate setup of ABS_MT_PRESSURE
  Input: atmel_mxt_ts - remove unnecessary debug on ENOMEM
  Input: atmel_mxt_ts - config CRC may start at T71
  Input: atmel_mxt_ts - refactor config update code to add context struct
  Input: atmel_mxt_ts - zero terminate config firmware file
  Input: atmel_mxt_ts - don't report zero pressure from T9
  Input: atmel_mxt_ts - move completion to after config crc is updated

Oleksandr Andrushchenko (3):
  xen: Sync up with the canonical protocol definitions in Xen
  Input: xen-kbdfront - fix multi-touch XenStore node's locations
  Input: xen-kbdfront - allow better run-time configuration

Ravi Chandra Sadineni (2):
  Input: cros_ec_keyb - remove check before calling pm_wakeup_event
  Input: i8042 - increment wakeup_count for the respective port

Sebastian Andrzej Siewior (1):
  Input: iforce - use GFP_KERNEL in iforce_get_id_packet()

Tim Schumacher (3):
  Input: iforce - reformat the packet dump output
  Input: iforce - assign BTN_DEAD only for specific devices
  Input: iforce - reorganize joystick configuration lists

Vinod Koul (2):
  Input: pm8941-pwrkey - abstract register offsets and event code
  Input: pm8941-pwrkey - add resin entry

Zhu Yi (1):
  Input: add bu21029 touch driver

Diffstat:


 Documentation/devicetree/bindings/input/keys.txt   |   8 +
 .../bindings/input/qcom,pm8941-pwrkey.txt  |  10 +
 .../bindings/input/touchscreen/bu21029.txt |  35 ++
 .../devicetree/bindings/input/touchscreen/eeti.txt |  30 ++
 MAINTAINERS|   7 +
 drivers/input/evbug.c  |   4 -
 drivers/input/evdev.c  |  16 +-
 drivers/input/gameport/emu10k1-gp.c|   4 -
 drivers/input/gameport/lightning.c |   4 -
 drivers/input/gameport/ns558.c |   4 -
 drivers/input/input.c

[git pull] Input updates for v4.19-rc0

2018-08-17 Thread Dmitry Torokhov

Hi Linus,

Please pull from:

git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus

to receive updates for the input subsystem. You will get:

- a new driver for Rohm BU21029 touch controller

- new bitmap APIs: bitmap_alloc, bitmap_zalloc and bitmap_free

- updates to Atmel, eeti. pxrc and iforce drivers

- assorted driver cleanups and fixes.

Changelog:
-

Andy Shevchenko (5):
  dm: Avoid namespace collision with bitmap API
  md: Avoid namespace collision with bitmap API
  bitmap: Add bitmap_alloc(), bitmap_zalloc() and bitmap_free()
  Input: gpio-keys - switch to bitmap_zalloc()
  Input: evdev - switch to bitmap API

Chen Zhong (1):
  dt-bindings: input: add common keyboard document bindings

Colin Ian King (1):
  Input: cros_ec_keyb - remove redundant variable num_cols

Daniel Mack (4):
  dt-bindings: input: touchscreen: add bindings for eeti touchscreen 
controller
  Input: eeti - add device tree matching table
  Input: eeti - drop module parameters, parse DT properties
  Input: eeti - fix link to documentation and email address in header

Dmitry Torokhov (6):
  Input: pxrc - fix freeing URB on device teardown
  Input: pxrc - move module device table closer to where it is used
  Input: pxrc - do not store unneeded data in driver structure
  Input: pxrc - flatten probe code
  Input: stop telling users to snail-mail Vojtech
  Input: do not use WARN() in input_alloc_absinfo()

Enric Balletbo i Serra (2):
  Input: cros_ec_keyb - make license text and MODULE_LICENSE match
  Input: cros_ec_keyb - switch to SPDX identifier

Fabio Estevam (5):
  Input: imx_keypad - switch to SPDX identifier
  Input: snvs_pwrkey - switch to SPDX identifier
  Input: fsl-imx25-tcq - switch to SPDX identifier
  Input: imx6ul_tsc - switch to SPDX identifier
  Input: egalax_ts - switch to SPDX identifier

Gustavo A. R. Silva (2):
  Input: raydium_i2c_ts - use true and false for boolean values
  Input: mark expected switch fall-throughs

Jia-Ju Bai (6):
  Input: wdt87xx_i2c - replace mdelay() with msleep() in wdt87xx_resume()
  Input: keyspan_remote - replace GFP_ATOMIC with GFP_KERNEL in 
keyspan_probe()
  Input: powermate - replace GFP_ATOMIC with GFP_KERNEL in 
powermate_alloc_buffers()
  Input: yealink - replace GFP_ATOMIC with GFP_KERNEL in usb_probe()
  Input: appletouch - replace GFP_ATOMIC with GFP_KERNEL
  Input: aiptek - replace GFP_ATOMIC with GFP_KERNEL in aiptek_probe()

Julia Lawall (1):
  Input: elan_i2c_smbus - cast sizeof to int for comparison

Marcus Folkesson (2):
  Input: pxrc - do not store USB device in private struct
  MAINTAINERS: Add PhoenixRC Flight Controller Adapter

Matti Vaittinen (1):
  Input: gpio_keys - add missing include to gpio_keys.h

Nick Dyer (9):
  Input: atmel_mxt_ts - only use first T9 instance
  Input: atmel_mxt_ts - use BIT() macro everywhere
  Input: atmel_mxt_ts - remove duplicate setup of ABS_MT_PRESSURE
  Input: atmel_mxt_ts - remove unnecessary debug on ENOMEM
  Input: atmel_mxt_ts - config CRC may start at T71
  Input: atmel_mxt_ts - refactor config update code to add context struct
  Input: atmel_mxt_ts - zero terminate config firmware file
  Input: atmel_mxt_ts - don't report zero pressure from T9
  Input: atmel_mxt_ts - move completion to after config crc is updated

Oleksandr Andrushchenko (3):
  xen: Sync up with the canonical protocol definitions in Xen
  Input: xen-kbdfront - fix multi-touch XenStore node's locations
  Input: xen-kbdfront - allow better run-time configuration

Ravi Chandra Sadineni (2):
  Input: cros_ec_keyb - remove check before calling pm_wakeup_event
  Input: i8042 - increment wakeup_count for the respective port

Sebastian Andrzej Siewior (1):
  Input: iforce - use GFP_KERNEL in iforce_get_id_packet()

Tim Schumacher (3):
  Input: iforce - reformat the packet dump output
  Input: iforce - assign BTN_DEAD only for specific devices
  Input: iforce - reorganize joystick configuration lists

Vinod Koul (2):
  Input: pm8941-pwrkey - abstract register offsets and event code
  Input: pm8941-pwrkey - add resin entry

Zhu Yi (1):
  Input: add bu21029 touch driver

Diffstat:


 Documentation/devicetree/bindings/input/keys.txt   |   8 +
 .../bindings/input/qcom,pm8941-pwrkey.txt  |  10 +
 .../bindings/input/touchscreen/bu21029.txt |  35 ++
 .../devicetree/bindings/input/touchscreen/eeti.txt |  30 ++
 MAINTAINERS|   7 +
 drivers/input/evbug.c  |   4 -
 drivers/input/evdev.c  |  16 +-
 drivers/input/gameport/emu10k1-gp.c|   4 -
 drivers/input/gameport/lightning.c |   4 -
 drivers/input/gameport/ns558.c |   4 -
 drivers/input/input.c

Re: [PATCH v2] gpio: brcmstb: allow 0 width GPIO banks

2018-08-17 Thread Andrew Lunn

On Fri, Aug 17, 2018 at 04:47:39PM -0700, justinpo...@gmail.com wrote:
> From: Justin Chen 
> 
> Sometimes we have empty banks within the GPIO block. This commit allows
> proper handling of 0 width GPIO banks.

Hi Justin

This is coming from DT? Why do you put 0 width banks in DT in the
first place?

  Andrew

Re: [PATCH v2] gpio: brcmstb: allow 0 width GPIO banks

2018-08-17 Thread Andrew Lunn

On Fri, Aug 17, 2018 at 04:47:39PM -0700, justinpo...@gmail.com wrote:
> From: Justin Chen 
> 
> Sometimes we have empty banks within the GPIO block. This commit allows
> proper handling of 0 width GPIO banks.

Hi Justin

This is coming from DT? Why do you put 0 width banks in DT in the
first place?

  Andrew

Re: Crash in MM code in v4.4.y, v4.9.y with TRANSPARENT_HUGEPAGE enabled


On 08/17/2018 05:25 PM, Linus Torvalds wrote:

On Fri, Aug 17, 2018 at 3:27 PM Guenter Roeck  wrote:


[6.649970] random: crng init done
[6.689002] BUG: unable to handle kernel paging request at eafffa1a0020


Hmm. Lots of bits set.


[6.689082] RIP: 0010:[]  [] 
page_remove_rmap+0x10/0x230
[6.689082] RSP: 0018:c97abc18  EFLAGS: 0296
[6.689082] RAX: ea0005e58000 RBX: eafffa1a RCX: 2020
[6.689082] RDX: 3fe0 RSI: 0001 RDI: eafffa1a


Is that RDX value the same value as PHYSICAL_PMD_PAGE_MASK?

If I did my math right, it would be, if your CPU has 46 bits of
physical memory. Might that be the case?


Yes.


The reason I mention that is because we had the bug with spurious
inversion of the zero pte/pmd, fixed by

   f19f5c49bbc3 ("x86/speculation/l1tf: Exempt zeroed PTEs from inversion")


I applied that patch, but it didn't help. I get exactly the same crash and
traceback.


and that would make a zeroed pmd entry be inverted by
PHYSICAL_PMD_PAGE_MASK, and then you get odd garbage page pointers
etc.

Maybe. I could have gotten the math wrong too, but it sounds like the
register contents _potentially_ might match up with something like
this, and then we'd zap a bogus hugepage because of some confusion.

Although then I'd have expected the bisection to hit
"x86/speculation/l1tf: Invert all not present mappings" instead of the
one you hit, so I don't know.

Plus I'd have expected the problem to have been in mainline too, and
apparently it's just the 4.4 and 4.9 backports.


Personally I suspect that something went wrong or is missing in the backport
from 4.14 to 4.9. 5-level paging was introduced in between, and thp support
was extended to support additional architectures. With all those changes,
it is easy to miss something. Only I have no idea what that might be.

Guenter

Re: [PATCH] fpga: dfl: region: Restory symmetry in probe()/remove()

On Fri, Aug 17, 2018 at 4:40 PM, Moritz Fischer  wrote:
> Replace dev_get_drvdata() with platform_get_drvdata() to
> match the platform_set_drvdata() in the probe function of
> the platform driver.
>
> Fixes commit bb61b9be3e6b ("fpga: dfl: add fpga region platform driver for
> FME")
> Signed-off-by: Moritz Fischer 
> ---
>  drivers/fpga/dfl-fme-region.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/fpga/dfl-fme-region.c b/drivers/fpga/dfl-fme-region.c
> index 0b7e19c27c6d..ce7ebe4b3212 100644
> --- a/drivers/fpga/dfl-fme-region.c
> +++ b/drivers/fpga/dfl-fme-region.c
> @@ -65,7 +65,7 @@ static int fme_region_probe(struct platform_device *pdev)
>
>  static int fme_region_remove(struct platform_device *pdev)
>  {
> -   struct fpga_region *region = dev_get_drvdata(>dev);
> +   struct fpga_region *region = platform_get_drvdata(>dev);
Blergh ... that doesn't even compile. I'll resubmit next week. Sorry
for the noise.
Should of course be platform_get_drvdata(pdev);

- Moritz

Re: Crash in MM code in v4.4.y, v4.9.y with TRANSPARENT_HUGEPAGE enabled


On 08/17/2018 05:25 PM, Linus Torvalds wrote:

On Fri, Aug 17, 2018 at 3:27 PM Guenter Roeck  wrote:


[6.649970] random: crng init done
[6.689002] BUG: unable to handle kernel paging request at eafffa1a0020


Hmm. Lots of bits set.


[6.689082] RIP: 0010:[]  [] 
page_remove_rmap+0x10/0x230
[6.689082] RSP: 0018:c97abc18  EFLAGS: 0296
[6.689082] RAX: ea0005e58000 RBX: eafffa1a RCX: 2020
[6.689082] RDX: 3fe0 RSI: 0001 RDI: eafffa1a


Is that RDX value the same value as PHYSICAL_PMD_PAGE_MASK?

If I did my math right, it would be, if your CPU has 46 bits of
physical memory. Might that be the case?


Yes.


The reason I mention that is because we had the bug with spurious
inversion of the zero pte/pmd, fixed by

   f19f5c49bbc3 ("x86/speculation/l1tf: Exempt zeroed PTEs from inversion")


I applied that patch, but it didn't help. I get exactly the same crash and
traceback.


and that would make a zeroed pmd entry be inverted by
PHYSICAL_PMD_PAGE_MASK, and then you get odd garbage page pointers
etc.

Maybe. I could have gotten the math wrong too, but it sounds like the
register contents _potentially_ might match up with something like
this, and then we'd zap a bogus hugepage because of some confusion.

Although then I'd have expected the bisection to hit
"x86/speculation/l1tf: Invert all not present mappings" instead of the
one you hit, so I don't know.

Plus I'd have expected the problem to have been in mainline too, and
apparently it's just the 4.4 and 4.9 backports.


Personally I suspect that something went wrong or is missing in the backport
from 4.14 to 4.9. 5-level paging was introduced in between, and thp support
was extended to support additional architectures. With all those changes,
it is easy to miss something. Only I have no idea what that might be.

Guenter

Re: [PATCH] fpga: dfl: region: Restory symmetry in probe()/remove()

On Fri, Aug 17, 2018 at 4:40 PM, Moritz Fischer  wrote:
> Replace dev_get_drvdata() with platform_get_drvdata() to
> match the platform_set_drvdata() in the probe function of
> the platform driver.
>
> Fixes commit bb61b9be3e6b ("fpga: dfl: add fpga region platform driver for
> FME")
> Signed-off-by: Moritz Fischer 
> ---
>  drivers/fpga/dfl-fme-region.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/fpga/dfl-fme-region.c b/drivers/fpga/dfl-fme-region.c
> index 0b7e19c27c6d..ce7ebe4b3212 100644
> --- a/drivers/fpga/dfl-fme-region.c
> +++ b/drivers/fpga/dfl-fme-region.c
> @@ -65,7 +65,7 @@ static int fme_region_probe(struct platform_device *pdev)
>
>  static int fme_region_remove(struct platform_device *pdev)
>  {
> -   struct fpga_region *region = dev_get_drvdata(>dev);
> +   struct fpga_region *region = platform_get_drvdata(>dev);
Blergh ... that doesn't even compile. I'll resubmit next week. Sorry
for the noise.
Should of course be platform_get_drvdata(pdev);

- Moritz

[PATCH] Cleanup "fat: propagate 64-bit inode timestamps" patch

2018-08-17 Thread OGAWA Hirofumi

Hi,

Looks like I missed the email to read for a patch
(mmots/broken-out/fat-propagate-64-bit-inode-timestamps.patch).  Well,
so FWIW,

Acked-by: OGAWA Hirofumi 

And additionally cleanup patch here (this would be better to be folded
into his patch).

Thanks.
-- 
OGAWA Hirofumi 

[PATCH] Cleanup "fat: propagate 64-bit inode timestamps" patch

- Remove useless temporary variable
- Remove needless long long

Signed-off-by: OGAWA Hirofumi 
---

 fs/fat/inode.c |   10 +++---
 fs/fat/misc.c  |7 +++
 2 files changed, 6 insertions(+), 11 deletions(-)

diff -puN fs/fat/inode.c~fat-propagate-64-bit-inode-timestamps-cleanup 
fs/fat/inode.c
--- linux/fs/fat/inode.c~fat-propagate-64-bit-inode-timestamps-cleanup  
2018-08-18 09:23:27.990137305 +0900
+++ linux-hirofumi/fs/fat/inode.c   2018-08-18 09:32:52.629008507 +0900
@@ -509,7 +509,6 @@ static int fat_validate_dir(struct inode
 int fat_fill_inode(struct inode *inode, struct msdos_dir_entry *de)
 {
struct msdos_sb_info *sbi = MSDOS_SB(inode->i_sb);
-   struct timespec64 ts;
int error;
 
MSDOS_I(inode)->i_pos = 0;
@@ -559,14 +558,11 @@ int fat_fill_inode(struct inode *inode,
inode->i_blocks = ((inode->i_size + (sbi->cluster_size - 1))
   & ~((loff_t)sbi->cluster_size - 1)) >> 9;
 
-   fat_time_fat2unix(sbi, , de->time, de->date, 0);
-   inode->i_mtime = ts;
+   fat_time_fat2unix(sbi, >i_mtime, de->time, de->date, 0);
if (sbi->options.isvfat) {
-   fat_time_fat2unix(sbi, , de->ctime,
+   fat_time_fat2unix(sbi, >i_ctime, de->ctime,
  de->cdate, de->ctime_cs);
-   inode->i_ctime = ts;
-   fat_time_fat2unix(sbi, , 0, de->adate, 0);
-   inode->i_atime = ts;
+   fat_time_fat2unix(sbi, >i_atime, 0, de->adate, 0);
} else
inode->i_ctime = inode->i_atime = inode->i_mtime;
 
diff -puN fs/fat/misc.c~fat-propagate-64-bit-inode-timestamps-cleanup 
fs/fat/misc.c
--- linux/fs/fat/misc.c~fat-propagate-64-bit-inode-timestamps-cleanup   
2018-08-18 09:23:27.992137301 +0900
+++ linux-hirofumi/fs/fat/misc.c2018-08-18 09:32:52.596008572 +0900
@@ -180,7 +180,7 @@ int fat_chain_add(struct inode *inode, i
 #define IS_LEAP_YEAR(y)(!((y) & 3) && (y) != YEAR_2100)
 
 /* Linear day numbers of the respective 1sts in non-leap years. */
-static time64_t days_in_year[] = {
+static long days_in_year[] = {
/* Jan  Feb  Mar  Apr  May  Jun  Jul  Aug  Sep  Oct  Nov  Dec */
0,   0,  31,  59,  90, 120, 151, 181, 212, 243, 273, 304, 334, 0, 0, 0,
 };
@@ -191,8 +191,7 @@ void fat_time_fat2unix(struct msdos_sb_i
 {
u16 time = le16_to_cpu(__time), date = le16_to_cpu(__date);
time64_t second;
-   long day, leap_day, month;
-   long long year;
+   long day, leap_day, month, year;
 
year  = date >> 9;
month = max(1, (date >> 5) & 0xf);
@@ -207,7 +206,7 @@ void fat_time_fat2unix(struct msdos_sb_i
second =  (time & 0x1f) << 1;
second += ((time >> 5) & 0x3f) * SECS_PER_MIN;
second += (time >> 11) * SECS_PER_HOUR;
-   second += (year * 365 + leap_day
+   second += (time64_t)(year * 365 + leap_day
   + days_in_year[month] + day
   + DAYS_DELTA) * SECS_PER_DAY;
 
_

[PATCH] Cleanup "fat: propagate 64-bit inode timestamps" patch

2018-08-17 Thread OGAWA Hirofumi

Hi,

Looks like I missed the email to read for a patch
(mmots/broken-out/fat-propagate-64-bit-inode-timestamps.patch).  Well,
so FWIW,

Acked-by: OGAWA Hirofumi 

And additionally cleanup patch here (this would be better to be folded
into his patch).

Thanks.
-- 
OGAWA Hirofumi 

[PATCH] Cleanup "fat: propagate 64-bit inode timestamps" patch

- Remove useless temporary variable
- Remove needless long long

Signed-off-by: OGAWA Hirofumi 
---

 fs/fat/inode.c |   10 +++---
 fs/fat/misc.c  |7 +++
 2 files changed, 6 insertions(+), 11 deletions(-)

diff -puN fs/fat/inode.c~fat-propagate-64-bit-inode-timestamps-cleanup 
fs/fat/inode.c
--- linux/fs/fat/inode.c~fat-propagate-64-bit-inode-timestamps-cleanup  
2018-08-18 09:23:27.990137305 +0900
+++ linux-hirofumi/fs/fat/inode.c   2018-08-18 09:32:52.629008507 +0900
@@ -509,7 +509,6 @@ static int fat_validate_dir(struct inode
 int fat_fill_inode(struct inode *inode, struct msdos_dir_entry *de)
 {
struct msdos_sb_info *sbi = MSDOS_SB(inode->i_sb);
-   struct timespec64 ts;
int error;
 
MSDOS_I(inode)->i_pos = 0;
@@ -559,14 +558,11 @@ int fat_fill_inode(struct inode *inode,
inode->i_blocks = ((inode->i_size + (sbi->cluster_size - 1))
   & ~((loff_t)sbi->cluster_size - 1)) >> 9;
 
-   fat_time_fat2unix(sbi, , de->time, de->date, 0);
-   inode->i_mtime = ts;
+   fat_time_fat2unix(sbi, >i_mtime, de->time, de->date, 0);
if (sbi->options.isvfat) {
-   fat_time_fat2unix(sbi, , de->ctime,
+   fat_time_fat2unix(sbi, >i_ctime, de->ctime,
  de->cdate, de->ctime_cs);
-   inode->i_ctime = ts;
-   fat_time_fat2unix(sbi, , 0, de->adate, 0);
-   inode->i_atime = ts;
+   fat_time_fat2unix(sbi, >i_atime, 0, de->adate, 0);
} else
inode->i_ctime = inode->i_atime = inode->i_mtime;
 
diff -puN fs/fat/misc.c~fat-propagate-64-bit-inode-timestamps-cleanup 
fs/fat/misc.c
--- linux/fs/fat/misc.c~fat-propagate-64-bit-inode-timestamps-cleanup   
2018-08-18 09:23:27.992137301 +0900
+++ linux-hirofumi/fs/fat/misc.c2018-08-18 09:32:52.596008572 +0900
@@ -180,7 +180,7 @@ int fat_chain_add(struct inode *inode, i
 #define IS_LEAP_YEAR(y)(!((y) & 3) && (y) != YEAR_2100)
 
 /* Linear day numbers of the respective 1sts in non-leap years. */
-static time64_t days_in_year[] = {
+static long days_in_year[] = {
/* Jan  Feb  Mar  Apr  May  Jun  Jul  Aug  Sep  Oct  Nov  Dec */
0,   0,  31,  59,  90, 120, 151, 181, 212, 243, 273, 304, 334, 0, 0, 0,
 };
@@ -191,8 +191,7 @@ void fat_time_fat2unix(struct msdos_sb_i
 {
u16 time = le16_to_cpu(__time), date = le16_to_cpu(__date);
time64_t second;
-   long day, leap_day, month;
-   long long year;
+   long day, leap_day, month, year;
 
year  = date >> 9;
month = max(1, (date >> 5) & 0xf);
@@ -207,7 +206,7 @@ void fat_time_fat2unix(struct msdos_sb_i
second =  (time & 0x1f) << 1;
second += ((time >> 5) & 0x3f) * SECS_PER_MIN;
second += (time >> 11) * SECS_PER_HOUR;
-   second += (year * 365 + leap_day
+   second += (time64_t)(year * 365 + leap_day
   + days_in_year[month] + day
   + DAYS_DELTA) * SECS_PER_DAY;
 
_

Re: Crash in MM code in v4.4.y, v4.9.y with TRANSPARENT_HUGEPAGE enabled

On Fri, Aug 17, 2018 at 3:27 PM Guenter Roeck  wrote:
>
> [6.649970] random: crng init done
> [6.689002] BUG: unable to handle kernel paging request at eafffa1a0020

Hmm. Lots of bits set.

> [6.689082] RIP: 0010:[]  [] 
> page_remove_rmap+0x10/0x230
> [6.689082] RSP: 0018:c97abc18  EFLAGS: 0296
> [6.689082] RAX: ea0005e58000 RBX: eafffa1a RCX: 
> 2020
> [6.689082] RDX: 3fe0 RSI: 0001 RDI: 
> eafffa1a

Is that RDX value the same value as PHYSICAL_PMD_PAGE_MASK?

If I did my math right, it would be, if your CPU has 46 bits of
physical memory. Might that be the case?

The reason I mention that is because we had the bug with spurious
inversion of the zero pte/pmd, fixed by

  f19f5c49bbc3 ("x86/speculation/l1tf: Exempt zeroed PTEs from inversion")

and that would make a zeroed pmd entry be inverted by
PHYSICAL_PMD_PAGE_MASK, and then you get odd garbage page pointers
etc.

Maybe. I could have gotten the math wrong too, but it sounds like the
register contents _potentially_ might match up with something like
this, and then we'd zap a bogus hugepage because of some confusion.

Although then I'd have expected the bisection to hit
"x86/speculation/l1tf: Invert all not present mappings" instead of the
one you hit, so I don't know.

Plus I'd have expected the problem to have been in mainline too, and
apparently it's just the 4.4 and 4.9 backports.

Your test-case does have mprotect with PROT_NONE. Which together with
that mask that *might* be PHYSICAL_PMD_PAGE_MASK makes me think it
might be related.

 Linus

Re: Crash in MM code in v4.4.y, v4.9.y with TRANSPARENT_HUGEPAGE enabled

On Fri, Aug 17, 2018 at 3:27 PM Guenter Roeck  wrote:
>
> [6.649970] random: crng init done
> [6.689002] BUG: unable to handle kernel paging request at eafffa1a0020

Hmm. Lots of bits set.

> [6.689082] RIP: 0010:[]  [] 
> page_remove_rmap+0x10/0x230
> [6.689082] RSP: 0018:c97abc18  EFLAGS: 0296
> [6.689082] RAX: ea0005e58000 RBX: eafffa1a RCX: 
> 2020
> [6.689082] RDX: 3fe0 RSI: 0001 RDI: 
> eafffa1a

Is that RDX value the same value as PHYSICAL_PMD_PAGE_MASK?

If I did my math right, it would be, if your CPU has 46 bits of
physical memory. Might that be the case?

The reason I mention that is because we had the bug with spurious
inversion of the zero pte/pmd, fixed by

  f19f5c49bbc3 ("x86/speculation/l1tf: Exempt zeroed PTEs from inversion")

and that would make a zeroed pmd entry be inverted by
PHYSICAL_PMD_PAGE_MASK, and then you get odd garbage page pointers
etc.

Maybe. I could have gotten the math wrong too, but it sounds like the
register contents _potentially_ might match up with something like
this, and then we'd zap a bogus hugepage because of some confusion.

Although then I'd have expected the bisection to hit
"x86/speculation/l1tf: Invert all not present mappings" instead of the
one you hit, so I don't know.

Plus I'd have expected the problem to have been in mainline too, and
apparently it's just the 4.4 and 4.9 backports.

Your test-case does have mprotect with PROT_NONE. Which together with
that mask that *might* be PHYSICAL_PMD_PAGE_MASK makes me think it
might be related.

 Linus

[PATCH v2 4/4] dt-bindigs: msm: Update documentation of qcom,llcc

Add reg-names and interrupts for LLCC documentation and the usage
examples. llcc broadcast base is added in addition to llcc base,
which is used for llcc broadcast writes.

Signed-off-by: Venkata Narendra Kumar Gutta 
---
 Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt 
b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
index 5e85749..b4b1c86 100644
--- a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
@@ -18,9 +18,22 @@ Properties:
Value Type: 
Definition: Start address and the the size of the register region.
 
+- reg-names:
+Usage: required
+Value Type: 
+Definition: Register region names. Must be "llcc_base", 
"llcc_bcast_base".
+
+- interrupts:
+   Usage: required
+   Definition: The interrupt is associated with the llcc edac device.
+   It's used for llcc cache single and double bit error 
detection
+   and reporting.
+
 Example:
 
cache-controller@110 {
compatible = "qcom,sdm845-llcc";
-   reg = <0x110 0x25>;
+   reg = <0x110 0x20>, <0x130 0x5> ;
+   reg-names = "llcc_base", "llcc_bcast_base";
+   interrupts = ;
};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 2/4] drivers: soc: Add support to register LLCC EDAC driver

Cache error reporting controller is to detect and report single
and double bit errors on Last Level Cache Controller (LLCC) cache.
Add required support to register LLCC EDAC driver as platform driver,
from LLCC driver.

Signed-off-by: Venkata Narendra Kumar Gutta 
---
 drivers/soc/qcom/llcc-slice.c  | 18 --
 include/linux/soc/qcom/llcc-qcom.h |  2 ++
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/qcom/llcc-slice.c b/drivers/soc/qcom/llcc-slice.c
index a63640d..09c8bb0 100644
--- a/drivers/soc/qcom/llcc-slice.c
+++ b/drivers/soc/qcom/llcc-slice.c
@@ -224,7 +224,7 @@ static int qcom_llcc_cfg_program(struct platform_device 
*pdev)
u32 attr0_val;
u32 max_cap_cacheline;
u32 sz;
-   int ret;
+   int ret = 0;
const struct llcc_slice_config *llcc_table;
struct llcc_slice_desc desc;
 
@@ -282,6 +282,7 @@ int qcom_llcc_probe(struct platform_device *pdev,
struct resource *llcc_banks_res, *llcc_bcast_res;
void __iomem *llcc_banks_base, *llcc_bcast_base;
int ret, i;
+   struct platform_device *llcc_edac;
 
drv_data = devm_kzalloc(dev, sizeof(*drv_data), GFP_KERNEL);
if (!drv_data)
@@ -341,6 +342,19 @@ int qcom_llcc_probe(struct platform_device *pdev,
mutex_init(_data->lock);
platform_set_drvdata(pdev, drv_data);
 
-   return qcom_llcc_cfg_program(pdev);
+   ret = qcom_llcc_cfg_program(pdev);
+   if (ret)
+   return ret;
+
+   drv_data->ecc_irq = platform_get_irq(pdev, 0);
+   if (drv_data->ecc_irq >= 0) {
+   llcc_edac = platform_device_register_data(>dev,
+   "qcom_llcc_edac", -1, drv_data,
+   sizeof(*drv_data));
+   if (IS_ERR(llcc_edac))
+   dev_err(dev, "Failed to register llcc edac driver\n");
+   }
+
+   return ret;
 }
 EXPORT_SYMBOL_GPL(qcom_llcc_probe);
diff --git a/include/linux/soc/qcom/llcc-qcom.h 
b/include/linux/soc/qcom/llcc-qcom.h
index c681e79..2e4b34d 100644
--- a/include/linux/soc/qcom/llcc-qcom.h
+++ b/include/linux/soc/qcom/llcc-qcom.h
@@ -78,6 +78,7 @@ struct llcc_slice_config {
  * @num_banks: Number of llcc banks
  * @bitmap: Bit map to track the active slice ids
  * @offsets: Pointer to the bank offsets array
+ * @ecc_irq: interrupt for llcc cache error detection and reporting
  */
 struct llcc_drv_data {
struct regmap *regmap;
@@ -89,6 +90,7 @@ struct llcc_drv_data {
u32 num_banks;
unsigned long *bitmap;
u32 *offsets;
+   int ecc_irq;
 };
 
 #if IS_ENABLED(CONFIG_QCOM_LLCC)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 4/4] dt-bindigs: msm: Update documentation of qcom,llcc

Add reg-names and interrupts for LLCC documentation and the usage
examples. llcc broadcast base is added in addition to llcc base,
which is used for llcc broadcast writes.

Signed-off-by: Venkata Narendra Kumar Gutta 
---
 Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt 
b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
index 5e85749..b4b1c86 100644
--- a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
@@ -18,9 +18,22 @@ Properties:
Value Type: 
Definition: Start address and the the size of the register region.
 
+- reg-names:
+Usage: required
+Value Type: 
+Definition: Register region names. Must be "llcc_base", 
"llcc_bcast_base".
+
+- interrupts:
+   Usage: required
+   Definition: The interrupt is associated with the llcc edac device.
+   It's used for llcc cache single and double bit error 
detection
+   and reporting.
+
 Example:
 
cache-controller@110 {
compatible = "qcom,sdm845-llcc";
-   reg = <0x110 0x25>;
+   reg = <0x110 0x20>, <0x130 0x5> ;
+   reg-names = "llcc_base", "llcc_bcast_base";
+   interrupts = ;
};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 2/4] drivers: soc: Add support to register LLCC EDAC driver

Cache error reporting controller is to detect and report single
and double bit errors on Last Level Cache Controller (LLCC) cache.
Add required support to register LLCC EDAC driver as platform driver,
from LLCC driver.

Signed-off-by: Venkata Narendra Kumar Gutta 
---
 drivers/soc/qcom/llcc-slice.c  | 18 --
 include/linux/soc/qcom/llcc-qcom.h |  2 ++
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/qcom/llcc-slice.c b/drivers/soc/qcom/llcc-slice.c
index a63640d..09c8bb0 100644
--- a/drivers/soc/qcom/llcc-slice.c
+++ b/drivers/soc/qcom/llcc-slice.c
@@ -224,7 +224,7 @@ static int qcom_llcc_cfg_program(struct platform_device 
*pdev)
u32 attr0_val;
u32 max_cap_cacheline;
u32 sz;
-   int ret;
+   int ret = 0;
const struct llcc_slice_config *llcc_table;
struct llcc_slice_desc desc;
 
@@ -282,6 +282,7 @@ int qcom_llcc_probe(struct platform_device *pdev,
struct resource *llcc_banks_res, *llcc_bcast_res;
void __iomem *llcc_banks_base, *llcc_bcast_base;
int ret, i;
+   struct platform_device *llcc_edac;
 
drv_data = devm_kzalloc(dev, sizeof(*drv_data), GFP_KERNEL);
if (!drv_data)
@@ -341,6 +342,19 @@ int qcom_llcc_probe(struct platform_device *pdev,
mutex_init(_data->lock);
platform_set_drvdata(pdev, drv_data);
 
-   return qcom_llcc_cfg_program(pdev);
+   ret = qcom_llcc_cfg_program(pdev);
+   if (ret)
+   return ret;
+
+   drv_data->ecc_irq = platform_get_irq(pdev, 0);
+   if (drv_data->ecc_irq >= 0) {
+   llcc_edac = platform_device_register_data(>dev,
+   "qcom_llcc_edac", -1, drv_data,
+   sizeof(*drv_data));
+   if (IS_ERR(llcc_edac))
+   dev_err(dev, "Failed to register llcc edac driver\n");
+   }
+
+   return ret;
 }
 EXPORT_SYMBOL_GPL(qcom_llcc_probe);
diff --git a/include/linux/soc/qcom/llcc-qcom.h 
b/include/linux/soc/qcom/llcc-qcom.h
index c681e79..2e4b34d 100644
--- a/include/linux/soc/qcom/llcc-qcom.h
+++ b/include/linux/soc/qcom/llcc-qcom.h
@@ -78,6 +78,7 @@ struct llcc_slice_config {
  * @num_banks: Number of llcc banks
  * @bitmap: Bit map to track the active slice ids
  * @offsets: Pointer to the bank offsets array
+ * @ecc_irq: interrupt for llcc cache error detection and reporting
  */
 struct llcc_drv_data {
struct regmap *regmap;
@@ -89,6 +90,7 @@ struct llcc_drv_data {
u32 num_banks;
unsigned long *bitmap;
u32 *offsets;
+   int ecc_irq;
 };
 
 #if IS_ENABLED(CONFIG_QCOM_LLCC)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 3/4] drivers: edac: Add EDAC driver support for QCOM SoCs

From: Channagoud Kadabi 

Add error reporting driver for Single Bit Errors (SBEs) and Double Bit
Errors (DBEs). As of now, this driver supports erp for Last Level Cache
Controller (LLCC). This driver takes care of dumping registers and adding
config options to enable and disable panic when the errors happen in cache.

Signed-off-by: Channagoud Kadabi 
Signed-off-by: Venkata Narendra Kumar Gutta 
Co-developed-by: Venkata Narendra Kumar Gutta 
---
 MAINTAINERS|   8 +
 drivers/edac/Kconfig   |  28 +++
 drivers/edac/Makefile  |   1 +
 drivers/edac/qcom_edac.c   | 446 +
 include/linux/soc/qcom/llcc-qcom.h |  25 +++
 5 files changed, 508 insertions(+)
 create mode 100644 drivers/edac/qcom_edac.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 0a23427..0bff713 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5227,6 +5227,14 @@ L:   linux-e...@vger.kernel.org
 S: Maintained
 F: drivers/edac/ti_edac.c
 
+EDAC-QUALCOMM
+M: Channagoud Kadabi 
+M: Venkata Narendra Kumar Gutta 
+L: linux-arm-...@vger.kernel.org
+L: linux-e...@vger.kernel.org
+S: Maintained
+F: drivers/edac/qcom_edac.c
+
 EDIROL UA-101/UA-1000 DRIVER
 M: Clemens Ladisch 
 L: alsa-de...@alsa-project.org (moderated for non-subscribers)
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 57304b2..da8f150 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -460,4 +460,32 @@ config EDAC_TI
  Support for error detection and correction on the
   TI SoCs.
 
+config EDAC_QCOM
+   tristate "QCOM EDAC Controller"
+   depends on EDAC
+   help
+ Support for error detection and correction on the
+ QCOM SoCs.
+
+config EDAC_QCOM_LLCC
+   tristate "QCOM EDAC Controller for LLCC Cache"
+   depends on EDAC_QCOM && QCOM_LLCC
+   help
+ Support for error detection and correction on the
+ QCOM LLCC cache. Report errors caught by LLCC ECC
+ mechanism.
+
+ For debugging issues having to do with stability and overall system
+  health, you should probably say 'Y' here.
+
+config EDAC_QCOM_LLCC_PANIC_ON_UE
+   bool "Panic on uncorrectable errors - qcom llcc"
+   depends on EDAC_QCOM_LLCC
+   help
+ Forcibly cause a kernel panic if an uncorrectable error (UE) is
+ detected. This can reduce debugging times on hardware which may be
+ operating at voltages or frequencies outside normal specification.
+
+ For production builds, you should probably say 'N' here.
+
 endif # EDAC
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 02b43a7..716096d 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -77,3 +77,4 @@ obj-$(CONFIG_EDAC_ALTERA) += altera_edac.o
 obj-$(CONFIG_EDAC_SYNOPSYS)+= synopsys_edac.o
 obj-$(CONFIG_EDAC_XGENE)   += xgene_edac.o
 obj-$(CONFIG_EDAC_TI)  += ti_edac.o
+obj-$(CONFIG_EDAC_QCOM)+= qcom_edac.o
diff --git a/drivers/edac/qcom_edac.c b/drivers/edac/qcom_edac.c
new file mode 100644
index 000..9a8c670
--- /dev/null
+++ b/drivers/edac/qcom_edac.c
@@ -0,0 +1,446 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "edac_mc.h"
+#include "edac_device.h"
+
+#ifdef CONFIG_EDAC_QCOM_LLCC_PANIC_ON_UE
+#define LLCC_ERP_PANIC_ON_UE1
+#else
+#define LLCC_ERP_PANIC_ON_UE0
+#endif
+
+#define EDAC_LLCC   "qcom_llcc"
+
+#define TRP_SYN_REG_CNT 6
+
+#define DRP_SYN_REG_CNT 8
+
+#define LLCC_COMMON_STATUS0 0x0003000C
+#define LLCC_LB_CNT_MASKGENMASK(31, 28)
+#define LLCC_LB_CNT_SHIFT   28
+
+/* single & Double Bit syndrome register offsets */
+#define TRP_ECC_SB_ERR_SYN0 0x0002304C
+#define TRP_ECC_DB_ERR_SYN0 0x00020370
+#define DRP_ECC_SB_ERR_SYN0 0x0004204C
+#define DRP_ECC_DB_ERR_SYN0 0x00042070
+
+/* Error register offsets */
+#define TRP_ECC_ERROR_STATUS1   0x00020348
+#define TRP_ECC_ERROR_STATUS0   0x00020344
+#define DRP_ECC_ERROR_STATUS1   0x00042048
+#define DRP_ECC_ERROR_STATUS0   0x00042044
+
+/* TRP, DRP interrupt register offsets */
+#define DRP_INTERRUPT_STATUS0x00041000
+#define TRP_INTERRUPT_0_STATUS  0x00020480
+#define DRP_INTERRUPT_CLEAR 0x00041008
+#define DRP_ECC_ERROR_CNTR_CLEAR0x00040004
+#define TRP_INTERRUPT_0_CLEAR   0x00020484
+#define TRP_ECC_ERROR_CNTR_CLEAR0x00020440
+
+/* Mask and shift macros */
+#define ECC_DB_ERR_COUNT_MASK   GENMASK(4, 0)
+#define ECC_DB_ERR_WAYS_MASKGENMASK(31, 16)
+#define ECC_DB_ERR_WAYS_SHIFT

[PATCH v2 0/4] Add EDAC driver for QCOM SoCs

This series implements EDAC driver for QCOM SoCs. As of now, this driver
supports EDAC for Last Level Cache Controller (LLCC). LLCC EDAC driver is
to detect and report single and double bit errors on Last Level Cache
Controller (LLCC) cache. This driver also takes care of dumping registers
and also adding config options to enable and disable panic when these
errors happen in LLCC.

The driver functionality is implemented in:
qcom_edac.c : This platform driver registers to edac framework and
handles the single and double bit errors in cache by registering
interrupt handlers.

llcc-slice.c: It invokes the llcc edac driver and passes platform
data to it.

This patchset depends on the LLCC driver, which is part of 4.19 release.
Link: https://patchwork.kernel.org/patch/10422531/
Link:
http://lists-archives.com/linux-kernel/29157082-dt-bindings-documentation-for-qcom-llcc.html

Patch wise description given below:

Patch 1 adds the broadcast base regmap for broadcast writes in llcc.

Patch 2 adds the required changes to register edac driver from llcc driver.

Patch 3 adds the EDAC driver support for QCOM SoCS.

Patch 4 updates the dt bindings of llcc.

Changes since v1:
* Modified the edac driver
- Removed duplicate functions that are used to dump the syndrome registers,
replaced that with a common function and a reg_data datastructure.
- Removed structure containing function pointers.
- Addressed comments on error handling to clear the interrupt status.
* updated Kconfig

Changes since v0:
* Added EDAC_QCOM config and updated the driver
* Addressed comments related to indentation and other minor ones

Channagoud Kadabi (1):
drivers: edac: Add EDAC driver support for QCOM SoCs

Venkata Narendra Kumar Gutta (3):
drivers: soc: Add broadcast base for Last Level Cache Controller
(LLCC)
drivers: soc: Add support to register LLCC EDAC driver
dt-bindigs: msm: Update documentation of qcom,llcc

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

[PATCH v2 1/4] drivers: soc: Add broadcast base for Last Level Cache Controller (LLCC)

Currently, boradcast base is set to end of the LLCC banks, which may
not be correct always. As the number of banks may vary for each chipset
and the broadcast base could be at a different address as well. This info
depends on the chipset, so get the broadcast base info from the device
tree (DT). Add broadcast base in LLCC driver and use this for broadcast
writes.

Signed-off-by: Venkata Narendra Kumar Gutta 
---
 drivers/soc/qcom/llcc-slice.c  | 55 +++---
 include/linux/soc/qcom/llcc-qcom.h |  4 +--
 2 files changed, 35 insertions(+), 24 deletions(-)

diff --git a/drivers/soc/qcom/llcc-slice.c b/drivers/soc/qcom/llcc-slice.c
index fcaad1a..a63640d 100644
--- a/drivers/soc/qcom/llcc-slice.c
+++ b/drivers/soc/qcom/llcc-slice.c
@@ -105,22 +105,24 @@ static int llcc_update_act_ctrl(u32 sid,
u32 slice_status;
int ret;
 
-   act_ctrl_reg = drv_data->bcast_off + LLCC_TRP_ACT_CTRLn(sid);
-   status_reg = drv_data->bcast_off + LLCC_TRP_STATUSn(sid);
+   act_ctrl_reg = LLCC_TRP_ACT_CTRLn(sid);
+   status_reg = LLCC_TRP_STATUSn(sid);
 
/* Set the ACTIVE trigger */
act_ctrl_reg_val |= ACT_CTRL_ACT_TRIG;
-   ret = regmap_write(drv_data->regmap, act_ctrl_reg, act_ctrl_reg_val);
+   ret = regmap_write(drv_data->bcast_regmap, act_ctrl_reg,
+   act_ctrl_reg_val);
if (ret)
return ret;
 
/* Clear the ACTIVE trigger */
act_ctrl_reg_val &= ~ACT_CTRL_ACT_TRIG;
-   ret = regmap_write(drv_data->regmap, act_ctrl_reg, act_ctrl_reg_val);
+   ret = regmap_write(drv_data->bcast_regmap, act_ctrl_reg,
+   act_ctrl_reg_val);
if (ret)
return ret;
 
-   ret = regmap_read_poll_timeout(drv_data->regmap, status_reg,
+   ret = regmap_read_poll_timeout(drv_data->bcast_regmap, status_reg,
  slice_status, !(slice_status & status),
  0, LLCC_STATUS_READ_DELAY);
return ret;
@@ -225,16 +227,13 @@ static int qcom_llcc_cfg_program(struct platform_device 
*pdev)
int ret;
const struct llcc_slice_config *llcc_table;
struct llcc_slice_desc desc;
-   u32 bcast_off = drv_data->bcast_off;
 
sz = drv_data->cfg_size;
llcc_table = drv_data->cfg;
 
for (i = 0; i < sz; i++) {
-   attr1_cfg = bcast_off +
-   LLCC_TRP_ATTR1_CFGn(llcc_table[i].slice_id);
-   attr0_cfg = bcast_off +
-   LLCC_TRP_ATTR0_CFGn(llcc_table[i].slice_id);
+   attr1_cfg = LLCC_TRP_ATTR1_CFGn(llcc_table[i].slice_id);
+   attr0_cfg = LLCC_TRP_ATTR0_CFGn(llcc_table[i].slice_id);
 
attr1_val = llcc_table[i].cache_mode;
attr1_val |= llcc_table[i].probe_target_ways <<
@@ -259,10 +258,12 @@ static int qcom_llcc_cfg_program(struct platform_device 
*pdev)
attr0_val = llcc_table[i].res_ways & ATTR0_RES_WAYS_MASK;
attr0_val |= llcc_table[i].bonus_ways << ATTR0_BONUS_WAYS_SHIFT;
 
-   ret = regmap_write(drv_data->regmap, attr1_cfg, attr1_val);
+   ret = regmap_write(drv_data->bcast_regmap, attr1_cfg,
+   attr1_val);
if (ret)
return ret;
-   ret = regmap_write(drv_data->regmap, attr0_cfg, attr0_val);
+   ret = regmap_write(drv_data->bcast_regmap, attr0_cfg,
+   attr0_val);
if (ret)
return ret;
if (llcc_table[i].activate_on_init) {
@@ -278,24 +279,36 @@ int qcom_llcc_probe(struct platform_device *pdev,
 {
u32 num_banks;
struct device *dev = >dev;
-   struct resource *res;
-   void __iomem *base;
+   struct resource *llcc_banks_res, *llcc_bcast_res;
+   void __iomem *llcc_banks_base, *llcc_bcast_base;
int ret, i;
 
drv_data = devm_kzalloc(dev, sizeof(*drv_data), GFP_KERNEL);
if (!drv_data)
return -ENOMEM;
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   base = devm_ioremap_resource(>dev, res);
-   if (IS_ERR(base))
-   return PTR_ERR(base);
+   llcc_banks_res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+   "llcc_base");
+   llcc_banks_base = devm_ioremap_resource(>dev, llcc_banks_res);
+   if (IS_ERR(llcc_banks_base))
+   return PTR_ERR(llcc_banks_base);
 
-   drv_data->regmap = devm_regmap_init_mmio(dev, base,
-   _regmap_config);
+   drv_data->regmap = devm_regmap_init_mmio(dev, llcc_banks_base,
+   _regmap_config);
if (IS_ERR(drv_data->regmap))
return

[PATCH v2 0/4] Add EDAC driver for QCOM SoCs

The driver functionality is implemented in:
qcom_edac.c : This platform driver registers to edac framework and
handles the single and double bit errors in cache by registering
interrupt handlers.

llcc-slice.c: It invokes the llcc edac driver and passes platform
data to it.

Patch wise description given below:

Patch 1 adds the broadcast base regmap for broadcast writes in llcc.

Patch 2 adds the required changes to register edac driver from llcc driver.

Patch 3 adds the EDAC driver support for QCOM SoCS.

Patch 4 updates the dt bindings of llcc.

Changes since v0:
* Added EDAC_QCOM config and updated the driver
* Addressed comments related to indentation and other minor ones

Channagoud Kadabi (1):
drivers: edac: Add EDAC driver support for QCOM SoCs

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

[PATCH v2 1/4] drivers: soc: Add broadcast base for Last Level Cache Controller (LLCC)

Currently, boradcast base is set to end of the LLCC banks, which may
not be correct always. As the number of banks may vary for each chipset
and the broadcast base could be at a different address as well. This info
depends on the chipset, so get the broadcast base info from the device
tree (DT). Add broadcast base in LLCC driver and use this for broadcast
writes.

Signed-off-by: Venkata Narendra Kumar Gutta 
---
 drivers/soc/qcom/llcc-slice.c  | 55 +++---
 include/linux/soc/qcom/llcc-qcom.h |  4 +--
 2 files changed, 35 insertions(+), 24 deletions(-)

diff --git a/drivers/soc/qcom/llcc-slice.c b/drivers/soc/qcom/llcc-slice.c
index fcaad1a..a63640d 100644
--- a/drivers/soc/qcom/llcc-slice.c
+++ b/drivers/soc/qcom/llcc-slice.c
@@ -105,22 +105,24 @@ static int llcc_update_act_ctrl(u32 sid,
u32 slice_status;
int ret;
 
-   act_ctrl_reg = drv_data->bcast_off + LLCC_TRP_ACT_CTRLn(sid);
-   status_reg = drv_data->bcast_off + LLCC_TRP_STATUSn(sid);
+   act_ctrl_reg = LLCC_TRP_ACT_CTRLn(sid);
+   status_reg = LLCC_TRP_STATUSn(sid);
 
/* Set the ACTIVE trigger */
act_ctrl_reg_val |= ACT_CTRL_ACT_TRIG;
-   ret = regmap_write(drv_data->regmap, act_ctrl_reg, act_ctrl_reg_val);
+   ret = regmap_write(drv_data->bcast_regmap, act_ctrl_reg,
+   act_ctrl_reg_val);
if (ret)
return ret;
 
/* Clear the ACTIVE trigger */
act_ctrl_reg_val &= ~ACT_CTRL_ACT_TRIG;
-   ret = regmap_write(drv_data->regmap, act_ctrl_reg, act_ctrl_reg_val);
+   ret = regmap_write(drv_data->bcast_regmap, act_ctrl_reg,
+   act_ctrl_reg_val);
if (ret)
return ret;
 
-   ret = regmap_read_poll_timeout(drv_data->regmap, status_reg,
+   ret = regmap_read_poll_timeout(drv_data->bcast_regmap, status_reg,
  slice_status, !(slice_status & status),
  0, LLCC_STATUS_READ_DELAY);
return ret;
@@ -225,16 +227,13 @@ static int qcom_llcc_cfg_program(struct platform_device 
*pdev)
int ret;
const struct llcc_slice_config *llcc_table;
struct llcc_slice_desc desc;
-   u32 bcast_off = drv_data->bcast_off;
 
sz = drv_data->cfg_size;
llcc_table = drv_data->cfg;
 
for (i = 0; i < sz; i++) {
-   attr1_cfg = bcast_off +
-   LLCC_TRP_ATTR1_CFGn(llcc_table[i].slice_id);
-   attr0_cfg = bcast_off +
-   LLCC_TRP_ATTR0_CFGn(llcc_table[i].slice_id);
+   attr1_cfg = LLCC_TRP_ATTR1_CFGn(llcc_table[i].slice_id);
+   attr0_cfg = LLCC_TRP_ATTR0_CFGn(llcc_table[i].slice_id);
 
attr1_val = llcc_table[i].cache_mode;
attr1_val |= llcc_table[i].probe_target_ways <<
@@ -259,10 +258,12 @@ static int qcom_llcc_cfg_program(struct platform_device 
*pdev)
attr0_val = llcc_table[i].res_ways & ATTR0_RES_WAYS_MASK;
attr0_val |= llcc_table[i].bonus_ways << ATTR0_BONUS_WAYS_SHIFT;
 
-   ret = regmap_write(drv_data->regmap, attr1_cfg, attr1_val);
+   ret = regmap_write(drv_data->bcast_regmap, attr1_cfg,
+   attr1_val);
if (ret)
return ret;
-   ret = regmap_write(drv_data->regmap, attr0_cfg, attr0_val);
+   ret = regmap_write(drv_data->bcast_regmap, attr0_cfg,
+   attr0_val);
if (ret)
return ret;
if (llcc_table[i].activate_on_init) {
@@ -278,24 +279,36 @@ int qcom_llcc_probe(struct platform_device *pdev,
 {
u32 num_banks;
struct device *dev = >dev;
-   struct resource *res;
-   void __iomem *base;
+   struct resource *llcc_banks_res, *llcc_bcast_res;
+   void __iomem *llcc_banks_base, *llcc_bcast_base;
int ret, i;
 
drv_data = devm_kzalloc(dev, sizeof(*drv_data), GFP_KERNEL);
if (!drv_data)
return -ENOMEM;
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   base = devm_ioremap_resource(>dev, res);
-   if (IS_ERR(base))
-   return PTR_ERR(base);
+   llcc_banks_res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+   "llcc_base");
+   llcc_banks_base = devm_ioremap_resource(>dev, llcc_banks_res);
+   if (IS_ERR(llcc_banks_base))
+   return PTR_ERR(llcc_banks_base);
 
-   drv_data->regmap = devm_regmap_init_mmio(dev, base,
-   _regmap_config);
+   drv_data->regmap = devm_regmap_init_mmio(dev, llcc_banks_base,
+   _regmap_config);
if (IS_ERR(drv_data->regmap))
return

[PATCH v2 3/4] drivers: edac: Add EDAC driver support for QCOM SoCs

From: Channagoud Kadabi 

Add error reporting driver for Single Bit Errors (SBEs) and Double Bit
Errors (DBEs). As of now, this driver supports erp for Last Level Cache
Controller (LLCC). This driver takes care of dumping registers and adding
config options to enable and disable panic when the errors happen in cache.

Signed-off-by: Channagoud Kadabi 
Signed-off-by: Venkata Narendra Kumar Gutta 
Co-developed-by: Venkata Narendra Kumar Gutta 
---
 MAINTAINERS|   8 +
 drivers/edac/Kconfig   |  28 +++
 drivers/edac/Makefile  |   1 +
 drivers/edac/qcom_edac.c   | 446 +
 include/linux/soc/qcom/llcc-qcom.h |  25 +++
 5 files changed, 508 insertions(+)
 create mode 100644 drivers/edac/qcom_edac.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 0a23427..0bff713 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5227,6 +5227,14 @@ L:   linux-e...@vger.kernel.org
 S: Maintained
 F: drivers/edac/ti_edac.c
 
+EDAC-QUALCOMM
+M: Channagoud Kadabi 
+M: Venkata Narendra Kumar Gutta 
+L: linux-arm-...@vger.kernel.org
+L: linux-e...@vger.kernel.org
+S: Maintained
+F: drivers/edac/qcom_edac.c
+
 EDIROL UA-101/UA-1000 DRIVER
 M: Clemens Ladisch 
 L: alsa-de...@alsa-project.org (moderated for non-subscribers)
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 57304b2..da8f150 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -460,4 +460,32 @@ config EDAC_TI
  Support for error detection and correction on the
   TI SoCs.
 
+config EDAC_QCOM
+   tristate "QCOM EDAC Controller"
+   depends on EDAC
+   help
+ Support for error detection and correction on the
+ QCOM SoCs.
+
+config EDAC_QCOM_LLCC
+   tristate "QCOM EDAC Controller for LLCC Cache"
+   depends on EDAC_QCOM && QCOM_LLCC
+   help
+ Support for error detection and correction on the
+ QCOM LLCC cache. Report errors caught by LLCC ECC
+ mechanism.
+
+ For debugging issues having to do with stability and overall system
+  health, you should probably say 'Y' here.
+
+config EDAC_QCOM_LLCC_PANIC_ON_UE
+   bool "Panic on uncorrectable errors - qcom llcc"
+   depends on EDAC_QCOM_LLCC
+   help
+ Forcibly cause a kernel panic if an uncorrectable error (UE) is
+ detected. This can reduce debugging times on hardware which may be
+ operating at voltages or frequencies outside normal specification.
+
+ For production builds, you should probably say 'N' here.
+
 endif # EDAC
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 02b43a7..716096d 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -77,3 +77,4 @@ obj-$(CONFIG_EDAC_ALTERA) += altera_edac.o
 obj-$(CONFIG_EDAC_SYNOPSYS)+= synopsys_edac.o
 obj-$(CONFIG_EDAC_XGENE)   += xgene_edac.o
 obj-$(CONFIG_EDAC_TI)  += ti_edac.o
+obj-$(CONFIG_EDAC_QCOM)+= qcom_edac.o
diff --git a/drivers/edac/qcom_edac.c b/drivers/edac/qcom_edac.c
new file mode 100644
index 000..9a8c670
--- /dev/null
+++ b/drivers/edac/qcom_edac.c
@@ -0,0 +1,446 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "edac_mc.h"
+#include "edac_device.h"
+
+#ifdef CONFIG_EDAC_QCOM_LLCC_PANIC_ON_UE
+#define LLCC_ERP_PANIC_ON_UE1
+#else
+#define LLCC_ERP_PANIC_ON_UE0
+#endif
+
+#define EDAC_LLCC   "qcom_llcc"
+
+#define TRP_SYN_REG_CNT 6
+
+#define DRP_SYN_REG_CNT 8
+
+#define LLCC_COMMON_STATUS0 0x0003000C
+#define LLCC_LB_CNT_MASKGENMASK(31, 28)
+#define LLCC_LB_CNT_SHIFT   28
+
+/* single & Double Bit syndrome register offsets */
+#define TRP_ECC_SB_ERR_SYN0 0x0002304C
+#define TRP_ECC_DB_ERR_SYN0 0x00020370
+#define DRP_ECC_SB_ERR_SYN0 0x0004204C
+#define DRP_ECC_DB_ERR_SYN0 0x00042070
+
+/* Error register offsets */
+#define TRP_ECC_ERROR_STATUS1   0x00020348
+#define TRP_ECC_ERROR_STATUS0   0x00020344
+#define DRP_ECC_ERROR_STATUS1   0x00042048
+#define DRP_ECC_ERROR_STATUS0   0x00042044
+
+/* TRP, DRP interrupt register offsets */
+#define DRP_INTERRUPT_STATUS0x00041000
+#define TRP_INTERRUPT_0_STATUS  0x00020480
+#define DRP_INTERRUPT_CLEAR 0x00041008
+#define DRP_ECC_ERROR_CNTR_CLEAR0x00040004
+#define TRP_INTERRUPT_0_CLEAR   0x00020484
+#define TRP_ECC_ERROR_CNTR_CLEAR0x00020440
+
+/* Mask and shift macros */
+#define ECC_DB_ERR_COUNT_MASK   GENMASK(4, 0)
+#define ECC_DB_ERR_WAYS_MASKGENMASK(31, 16)
+#define ECC_DB_ERR_WAYS_SHIFT

Re: [GIT PULL] Please pull RDMA subsystem changes

On Fri, Aug 17, 2018 at 2:17 PM Jason Gunthorpe  wrote:
>
> Would you like a patch to remove that CONFIG option?

I've definitely considered it and would almost certainly just apply a
patch that removed it.

We haven't had this issue for a while (because people stopped using
the deprecated thing), so it ended up not having been an issue lately.
Yours was the first case of deprecation warnings I've seen in a
longish while.

  Linus

Re: [GIT PULL] Please pull RDMA subsystem changes

On Fri, Aug 17, 2018 at 2:17 PM Jason Gunthorpe  wrote:
>
> Would you like a patch to remove that CONFIG option?

I've definitely considered it and would almost certainly just apply a
patch that removed it.

We haven't had this issue for a while (because people stopped using
the deprecated thing), so it ended up not having been an issue lately.
Yours was the first case of deprecation warnings I've seen in a
longish while.

  Linus

[PATCH] fpga: dfl: region: Restory symmetry in probe()/remove()

Replace dev_get_drvdata() with platform_get_drvdata() to
match the platform_set_drvdata() in the probe function of
the platform driver.

Fixes commit bb61b9be3e6b ("fpga: dfl: add fpga region platform driver for
FME")
Signed-off-by: Moritz Fischer 
---
 drivers/fpga/dfl-fme-region.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/fpga/dfl-fme-region.c b/drivers/fpga/dfl-fme-region.c
index 0b7e19c27c6d..ce7ebe4b3212 100644
--- a/drivers/fpga/dfl-fme-region.c
+++ b/drivers/fpga/dfl-fme-region.c
@@ -65,7 +65,7 @@ static int fme_region_probe(struct platform_device *pdev)
 
 static int fme_region_remove(struct platform_device *pdev)
 {
-   struct fpga_region *region = dev_get_drvdata(>dev);
+   struct fpga_region *region = platform_get_drvdata(>dev);
 
fpga_region_unregister(region);
fpga_mgr_put(region->mgr);
-- 
2.18.0

[PATCH] fpga: dfl: region: Restory symmetry in probe()/remove()

Replace dev_get_drvdata() with platform_get_drvdata() to
match the platform_set_drvdata() in the probe function of
the platform driver.

Fixes commit bb61b9be3e6b ("fpga: dfl: add fpga region platform driver for
FME")
Signed-off-by: Moritz Fischer 
---
 drivers/fpga/dfl-fme-region.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/fpga/dfl-fme-region.c b/drivers/fpga/dfl-fme-region.c
index 0b7e19c27c6d..ce7ebe4b3212 100644
--- a/drivers/fpga/dfl-fme-region.c
+++ b/drivers/fpga/dfl-fme-region.c
@@ -65,7 +65,7 @@ static int fme_region_probe(struct platform_device *pdev)
 
 static int fme_region_remove(struct platform_device *pdev)
 {
-   struct fpga_region *region = dev_get_drvdata(>dev);
+   struct fpga_region *region = platform_get_drvdata(>dev);
 
fpga_region_unregister(region);
fpga_mgr_put(region->mgr);
-- 
2.18.0

Re: [PATCH v2] gpio: brcmstb: allow 0 width GPIO banks

2018-08-17 Thread Florian Fainelli

On 08/17/2018 04:47 PM, justinpo...@gmail.com wrote:
> From: Justin Chen 
> 
> Sometimes we have empty banks within the GPIO block. This commit allows
> proper handling of 0 width GPIO banks. We handle 0 width GPIO banks by
> incrementing the bank and number of GPIOs, but not initializing them.
> This will mean a call into the non-existent GPIOs will return an error.
> 
> Also remove "GPIO registered" dev print. This information is misleading
> since the incremented banks and gpio_base do not reflect the actual GPIOs
> that get initialized. We leave this information out since it is already
> printed with dev_dbg.
> 
> Signed-off-by: Justin Chen 

Acked-by: Florian Fainelli 

Thanks Justin!
--
Florian

Re: [PATCH v2] gpio: brcmstb: allow 0 width GPIO banks

2018-08-17 Thread Florian Fainelli

On 08/17/2018 04:47 PM, justinpo...@gmail.com wrote:
> From: Justin Chen 
> 
> Sometimes we have empty banks within the GPIO block. This commit allows
> proper handling of 0 width GPIO banks. We handle 0 width GPIO banks by
> incrementing the bank and number of GPIOs, but not initializing them.
> This will mean a call into the non-existent GPIOs will return an error.
> 
> Also remove "GPIO registered" dev print. This information is misleading
> since the incremented banks and gpio_base do not reflect the actual GPIOs
> that get initialized. We leave this information out since it is already
> printed with dev_dbg.
> 
> Signed-off-by: Justin Chen 

Acked-by: Florian Fainelli 

Thanks Justin!
--
Florian

[PATCH v2] gpio: brcmstb: allow 0 width GPIO banks

2018-08-17 Thread justinpopo6

From: Justin Chen 

Sometimes we have empty banks within the GPIO block. This commit allows
proper handling of 0 width GPIO banks. We handle 0 width GPIO banks by
incrementing the bank and number of GPIOs, but not initializing them.
This will mean a call into the non-existent GPIOs will return an error.

Also remove "GPIO registered" dev print. This information is misleading
since the incremented banks and gpio_base do not reflect the actual GPIOs
that get initialized. We leave this information out since it is already
printed with dev_dbg.

Signed-off-by: Justin Chen 
---
 drivers/gpio/gpio-brcmstb.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/gpio-brcmstb.c b/drivers/gpio/gpio-brcmstb.c
index 16c7f9f..af936dc 100644
--- a/drivers/gpio/gpio-brcmstb.c
+++ b/drivers/gpio/gpio-brcmstb.c
@@ -664,6 +664,18 @@ static int brcmstb_gpio_probe(struct platform_device *pdev)
struct brcmstb_gpio_bank *bank;
struct gpio_chip *gc;
 
+   /*
+* If bank_width is 0, then there is an empty bank in the
+* register block. Special handling for this case.
+*/
+   if (bank_width == 0) {
+   dev_dbg(dev, "Width 0 found: Empty bank @ %d\n",
+   num_banks);
+   num_banks++;
+   gpio_base += MAX_GPIO_PER_BANK;
+   continue;
+   }
+
bank = devm_kzalloc(dev, sizeof(*bank), GFP_KERNEL);
if (!bank) {
err = -ENOMEM;
@@ -740,9 +752,6 @@ static int brcmstb_gpio_probe(struct platform_device *pdev)
goto fail;
}
 
-   dev_info(dev, "Registered %d banks (GPIO(s): %d-%d)\n",
-   num_banks, priv->gpio_base, gpio_base - 1);
-
if (priv->parent_wake_irq && need_wakeup_event)
pm_wakeup_event(dev, 0);
 
-- 
2.7.4

[PATCH v2] gpio: brcmstb: allow 0 width GPIO banks

2018-08-17 Thread justinpopo6

From: Justin Chen 

Sometimes we have empty banks within the GPIO block. This commit allows
proper handling of 0 width GPIO banks. We handle 0 width GPIO banks by
incrementing the bank and number of GPIOs, but not initializing them.
This will mean a call into the non-existent GPIOs will return an error.

Also remove "GPIO registered" dev print. This information is misleading
since the incremented banks and gpio_base do not reflect the actual GPIOs
that get initialized. We leave this information out since it is already
printed with dev_dbg.

Signed-off-by: Justin Chen 
---
 drivers/gpio/gpio-brcmstb.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/gpio-brcmstb.c b/drivers/gpio/gpio-brcmstb.c
index 16c7f9f..af936dc 100644
--- a/drivers/gpio/gpio-brcmstb.c
+++ b/drivers/gpio/gpio-brcmstb.c
@@ -664,6 +664,18 @@ static int brcmstb_gpio_probe(struct platform_device *pdev)
struct brcmstb_gpio_bank *bank;
struct gpio_chip *gc;
 
+   /*
+* If bank_width is 0, then there is an empty bank in the
+* register block. Special handling for this case.
+*/
+   if (bank_width == 0) {
+   dev_dbg(dev, "Width 0 found: Empty bank @ %d\n",
+   num_banks);
+   num_banks++;
+   gpio_base += MAX_GPIO_PER_BANK;
+   continue;
+   }
+
bank = devm_kzalloc(dev, sizeof(*bank), GFP_KERNEL);
if (!bank) {
err = -ENOMEM;
@@ -740,9 +752,6 @@ static int brcmstb_gpio_probe(struct platform_device *pdev)
goto fail;
}
 
-   dev_info(dev, "Registered %d banks (GPIO(s): %d-%d)\n",
-   num_banks, priv->gpio_base, gpio_base - 1);
-
if (priv->parent_wake_irq && need_wakeup_event)
pm_wakeup_event(dev, 0);
 
-- 
2.7.4

Dear Friend,

2018-08-17 Thread Luiscarlosdelgado

Dear Friend, My   sincere   apologies   for   this   unsolicited   mail   to   
you,   my   name   is   Barrister   Luis   Carlos   Delgado,   theCEO/founder 
of (LCD ABOGADOS) with offices in Madrid and Portugal. We consult for NGOs, 
Companiesand individuals on Family Law, Intellectual Property, Real Estate, and 
Wills. I am consulting you on business grounds: I know that it may surprise you 
receiving this mail from me since therewas   no   previous   correspondence   
between   us.   I   have   an   urgent   and   very   confidential   business   
proposal   of(USD$9,500,000.00) (Nine Million Five Hundred Thousand US Dollars 
only) which I believe that will be a verygood opportunity for both of us, so I 
decided to contact you on the business. Further details; get back me on my 
direct contact number below: Tel: +351920414587Fax: +34917692994E-mail: 
Luis_carlos.delgado@consultant.comYour swift response will be highly 
recommended and appreciated, and I shall provide you with more detailsabout my 
urgent business proposal.Note: If my approach offends your moral ethics do 
accept my sincere apology, if on the contrary you wish towork with me on this, 
kindly get back to me with your interest for more details on my direct private 
contact.Best Regards,   
 Luis Carlos Delgado Esq.(LCD ABOGADOS) 
Av. de Burgos 20, 28036 Madrid EspanaRua Sarmento de Beires 30 1ºE, 1900-221 
Lisboa PortugalTel: +351920414587Fax: +34917692994E-mail: 
luis_carlos.delg...@consultant.co

Dear Friend,

2018-08-17 Thread Luiscarlosdelgado

Dear Friend, My   sincere   apologies   for   this   unsolicited   mail   to   
you,   my   name   is   Barrister   Luis   Carlos   Delgado,   theCEO/founder 
of (LCD ABOGADOS) with offices in Madrid and Portugal. We consult for NGOs, 
Companiesand individuals on Family Law, Intellectual Property, Real Estate, and 
Wills. I am consulting you on business grounds: I know that it may surprise you 
receiving this mail from me since therewas   no   previous   correspondence   
between   us.   I   have   an   urgent   and   very   confidential   business   
proposal   of(USD$9,500,000.00) (Nine Million Five Hundred Thousand US Dollars 
only) which I believe that will be a verygood opportunity for both of us, so I 
decided to contact you on the business. Further details; get back me on my 
direct contact number below: Tel: +351920414587Fax: +34917692994E-mail: 
Luis_carlos.delgado@consultant.comYour swift response will be highly 
recommended and appreciated, and I shall provide you with more detailsabout my 
urgent business proposal.Note: If my approach offends your moral ethics do 
accept my sincere apology, if on the contrary you wish towork with me on this, 
kindly get back to me with your interest for more details on my direct private 
contact.Best Regards,   
 Luis Carlos Delgado Esq.(LCD ABOGADOS) 
Av. de Burgos 20, 28036 Madrid EspanaRua Sarmento de Beires 30 1ºE, 1900-221 
Lisboa PortugalTel: +351920414587Fax: +34917692994E-mail: 
luis_carlos.delg...@consultant.co

[PATCH RFC] mm: don't miss the last page because of round-off error

2018-08-17 Thread Roman Gushchin

I've noticed, that dying memory cgroups are  often pinned
in memory by a single pagecache page. Even under moderate
memory pressure they sometimes stayed in such state
for a long time. That looked strange.

My investigation showed that the problem is caused by
applying the LRU pressure balancing math:

  scan = div64_u64(scan * fraction[lru], denominator),

where

  denominator = fraction[anon] + fraction[file] + 1.

Because fraction[lru] is always less than denominator,
if the initial scan size is 1, the result is always 0.

This means the last page is not scanned and has
no chances to be reclaimed.

Fix this by skipping the balancing logic if the initial
scan count is 1.

In practice this change significantly improves the speed
of dying cgroups reclaim.

Signed-off-by: Roman Gushchin 
Cc: Andrew Morton 
Cc: Johannes Weiner 
Cc: Michal Hocko 
Cc: Tejun Heo 
Cc: Rik van Riel 
Cc: Konstantin Khlebnikov 
---
 mm/vmscan.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 03822f86f288..f85c5ec01886 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2287,9 +2287,12 @@ static void get_scan_count(struct lruvec *lruvec, struct 
mem_cgroup *memcg,
/*
 * Scan types proportional to swappiness and
 * their relative recent reclaim efficiency.
+* Make sure we don't miss the last page
+* because of a round-off error.
 */
-   scan = div64_u64(scan * fraction[file],
-denominator);
+   if (scan > 1)
+   scan = div64_u64(scan * fraction[file],
+denominator);
break;
case SCAN_FILE:
case SCAN_ANON:
-- 
2.17.1

[PATCH RFC] mm: don't miss the last page because of round-off error

2018-08-17 Thread Roman Gushchin

I've noticed, that dying memory cgroups are  often pinned
in memory by a single pagecache page. Even under moderate
memory pressure they sometimes stayed in such state
for a long time. That looked strange.

My investigation showed that the problem is caused by
applying the LRU pressure balancing math:

  scan = div64_u64(scan * fraction[lru], denominator),

where

  denominator = fraction[anon] + fraction[file] + 1.

Because fraction[lru] is always less than denominator,
if the initial scan size is 1, the result is always 0.

This means the last page is not scanned and has
no chances to be reclaimed.

Fix this by skipping the balancing logic if the initial
scan count is 1.

In practice this change significantly improves the speed
of dying cgroups reclaim.

Signed-off-by: Roman Gushchin 
Cc: Andrew Morton 
Cc: Johannes Weiner 
Cc: Michal Hocko 
Cc: Tejun Heo 
Cc: Rik van Riel 
Cc: Konstantin Khlebnikov 
---
 mm/vmscan.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 03822f86f288..f85c5ec01886 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2287,9 +2287,12 @@ static void get_scan_count(struct lruvec *lruvec, struct 
mem_cgroup *memcg,
/*
 * Scan types proportional to swappiness and
 * their relative recent reclaim efficiency.
+* Make sure we don't miss the last page
+* because of a round-off error.
 */
-   scan = div64_u64(scan * fraction[file],
-denominator);
+   if (scan > 1)
+   scan = div64_u64(scan * fraction[file],
+denominator);
break;
case SCAN_FILE:
case SCAN_ANON:
-- 
2.17.1

Re: Should we split the network filesystem setup into two phases?

2018-08-17 Thread Al Viro

On Thu, Aug 16, 2018 at 12:06:06AM -0500, Eric W. Biederman wrote:

> So I don't think we can completely abandon the option for filesystems
> to always create a new filesystem instance when mount(8) is called.

Huh?  If filesystem wants to create a new instance on each ->mount(),
it can bloody well do so.  Quite a few do - if that fs can handle
that, more power to it.

The problem is what to do with filesystems that *can't* do that.
You really, really can't have two ext4 (or xfs, etc.) instances over
the same device at the same time.  Cache coherency, locking, etc.
will kill you.

And that's not to mention the joy of defining the semantics of
having the same ext4 mounted with two logs at the same time ;-)

I've seen "reject unless the options are compatible/identical/whatever",
but that ignores the real problem with existing policy.  It's *NOT*
"I've mounted this and got an existing instance with non-matching
options".  That's a minor annoyance (and back when that decision
had been made, mount(2) was very definitly root-only).  The real
problem is different and much worse - it's remount.

I have asked to mount something and it had already been mounted,
with identical options.  OK, so what happens if I do mount -o remount
on my instance?  *IF* we are operating in the "only sysadmin can
mount new filesystems", it's not a big deal - there are already
lots of ways you can shoot yourself in the foot and mount(2) is
certainly a powerful one.  But if we get to "Joe R. Luser can do
it in his container", we have a big problem.

Decision back then had been mostly for usability reasons - it was
back in 2001 (well before the containermania, userns or anything
of that sort) and it was more about "how many hoops does one have
to jump through to get something mounted, assuming the sanity of
sysadmin doing that?".  If *anything* like userns had been a concern
back then, it probably would've been different.  However, it's
17 years too late and if anyone has a functional TARDIS, I can
easily think of better uses for it...

Re: Should we split the network filesystem setup into two phases?

2018-08-17 Thread Al Viro

On Thu, Aug 16, 2018 at 12:06:06AM -0500, Eric W. Biederman wrote:

> So I don't think we can completely abandon the option for filesystems
> to always create a new filesystem instance when mount(8) is called.

Huh?  If filesystem wants to create a new instance on each ->mount(),
it can bloody well do so.  Quite a few do - if that fs can handle
that, more power to it.

The problem is what to do with filesystems that *can't* do that.
You really, really can't have two ext4 (or xfs, etc.) instances over
the same device at the same time.  Cache coherency, locking, etc.
will kill you.

And that's not to mention the joy of defining the semantics of
having the same ext4 mounted with two logs at the same time ;-)

I've seen "reject unless the options are compatible/identical/whatever",
but that ignores the real problem with existing policy.  It's *NOT*
"I've mounted this and got an existing instance with non-matching
options".  That's a minor annoyance (and back when that decision
had been made, mount(2) was very definitly root-only).  The real
problem is different and much worse - it's remount.

I have asked to mount something and it had already been mounted,
with identical options.  OK, so what happens if I do mount -o remount
on my instance?  *IF* we are operating in the "only sysadmin can
mount new filesystems", it's not a big deal - there are already
lots of ways you can shoot yourself in the foot and mount(2) is
certainly a powerful one.  But if we get to "Joe R. Luser can do
it in his container", we have a big problem.

Decision back then had been mostly for usability reasons - it was
back in 2001 (well before the containermania, userns or anything
of that sort) and it was more about "how many hoops does one have
to jump through to get something mounted, assuming the sanity of
sysadmin doing that?".  If *anything* like userns had been a concern
back then, it probably would've been different.  However, it's
17 years too late and if anyone has a functional TARDIS, I can
easily think of better uses for it...

mmotm 2018-08-17-15-48 uploaded

2018-08-17 Thread akpm

The mm-of-the-moment snapshot 2018-08-17-15-48 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (4.x
or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.

A git tree which contains the memory management portion of this tree is
maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
by Michal Hocko.  It contains the patches which are between the
"#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
file, http://www.ozlabs.org/~akpm/mmotm/series.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/

To develop on top of mmotm git:

  $ git remote add mmotm 
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
  $ git remote update mmotm
  $ git checkout -b topic mmotm/master
  
  $ git send-email mmotm/master.. [...]

To rebase a branch with older patches to a new mmotm release:

  $ git remote update mmotm
  $ git rebase --onto mmotm/master  topic




The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/

and use of this tree is similar to
http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.


This mmotm tree contains the following patches against 4.18:
(patches marked "*" will be included in linux-next)

  origin.patch
  i-need-old-gcc.patch
* 9p-remove-ron-minnich-from-maintainers.patch
* 9p-add-dominique-martinet-to-maintainers.patch
* bitfield-avoid-gcc-8-wint-in-bool-context-warning.patch
* dax-remove-vm_mixedmap-for-fsdax-and-device-dax.patch
* firewire-use-64-bit-time_t-based-interfaces.patch
* ufs-use-ktime_get_real_seconds-for-sb-and-cg-timestamps.patch
* ntfs-use-timespec64-directly-for-timestamp-conversion.patch
* hpfs-extend-gmt_to_local-conversion-to-64-bit-times.patch
* spdxcheck-work-with-current-head-licenses-directory.patch
* scripts-add-python-3-compatibility-to-spdxcheckpy.patch
* ntfs-dont-disable-interrupts-during-kmap_atomic.patch
* ntfs-aops-remove-vla-usage.patch
* ntfs-decompress-remove-vla-usage.patch
* ntfs-mft-remove-vla-usage.patch
* sh-make-use-of-for_each_node_by_type.patch
* sh-prefer-_this_ip_-to-current_text_addr.patch
* ocfs2-return-erofs-when-filesystem-becomes-read-only.patch
* ocfs2-clean-up-some-unnecessary-code.patch
* ocfs2-make-several-functions-and-variables-static-and-some-const.patch
* dentry-fix-kmemcheck-splat-at-take_dentry_name_snapshot.patch
* vfs-discard-attr_attr_flag.patch
* vfs-simplify-seq_file-iteration-code-and-interface.patch
* mm-slub-restore-the-original-intention-of-prefetch_freepointer.patch
* mm-convert-return-type-of-handle_mm_fault-caller-to-vm_fault_t.patch
* mm-skip-invalid-pages-block-at-a-time-in-zero_resv_unresv.patch
* thp-use-mm_file_counter-to-determine-update-which-rss-counter.patch
* tools-modifying-page-types-to-include-shared-map-counts.patch
* tools-adding-support-for-idle-page-tracking-to-tool.patch
* mm-page_alloc-actually-ignore-mempolicies-for-high-priority-allocations.patch
* shmem-use-monotonic-time-for-i_generation.patch
* mm-page_ext-drop-definition-of-unused-page_ext_debug_poison.patch
* mm-page_ext-constify-lookup_page_ext-argument.patch
* mm-condense-scan_control.patch
* 
mm-mempool-remove-unused-argument-in-kasan_unpoison_element-and-remove_element.patch
* mm-thp-register-mm-for-khugepaged-when-merging-vma-for-shmem-v3.patch
* mm-thp-inc-counter-for-collapsed-shmem-thp.patch
* mpage-add-argument-structure-for-do_mpage_readpage.patch
* mpage-mpage_readpages-should-submit-io-as-read-ahead.patch
* btrfs-readpages-should-submit-io-as-read-ahead.patch
* ext4-readpages-should-submit-io-as-read-ahead.patch
* mm-clear_huge_page-move-order-algorithm-into-a-separate-function.patch
* mm-huge-page-copy-target-sub-page-last-when-copy-huge-page.patch
* mm-hugetlbfs-rename-address-to-haddr-in-hugetlb_cow.patch
*

mmotm 2018-08-17-15-48 uploaded

2018-08-17 Thread akpm

The mm-of-the-moment snapshot 2018-08-17-15-48 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (4.x
or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.

A git tree which contains the memory management portion of this tree is
maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
by Michal Hocko.  It contains the patches which are between the
"#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
file, http://www.ozlabs.org/~akpm/mmotm/series.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/

To develop on top of mmotm git:

  $ git remote add mmotm 
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
  $ git remote update mmotm
  $ git checkout -b topic mmotm/master
  
  $ git send-email mmotm/master.. [...]

To rebase a branch with older patches to a new mmotm release:

  $ git remote update mmotm
  $ git rebase --onto mmotm/master  topic




The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/

and use of this tree is similar to
http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.


This mmotm tree contains the following patches against 4.18:
(patches marked "*" will be included in linux-next)

  origin.patch
  i-need-old-gcc.patch
* 9p-remove-ron-minnich-from-maintainers.patch
* 9p-add-dominique-martinet-to-maintainers.patch
* bitfield-avoid-gcc-8-wint-in-bool-context-warning.patch
* dax-remove-vm_mixedmap-for-fsdax-and-device-dax.patch
* firewire-use-64-bit-time_t-based-interfaces.patch
* ufs-use-ktime_get_real_seconds-for-sb-and-cg-timestamps.patch
* ntfs-use-timespec64-directly-for-timestamp-conversion.patch
* hpfs-extend-gmt_to_local-conversion-to-64-bit-times.patch
* spdxcheck-work-with-current-head-licenses-directory.patch
* scripts-add-python-3-compatibility-to-spdxcheckpy.patch
* ntfs-dont-disable-interrupts-during-kmap_atomic.patch
* ntfs-aops-remove-vla-usage.patch
* ntfs-decompress-remove-vla-usage.patch
* ntfs-mft-remove-vla-usage.patch
* sh-make-use-of-for_each_node_by_type.patch
* sh-prefer-_this_ip_-to-current_text_addr.patch
* ocfs2-return-erofs-when-filesystem-becomes-read-only.patch
* ocfs2-clean-up-some-unnecessary-code.patch
* ocfs2-make-several-functions-and-variables-static-and-some-const.patch
* dentry-fix-kmemcheck-splat-at-take_dentry_name_snapshot.patch
* vfs-discard-attr_attr_flag.patch
* vfs-simplify-seq_file-iteration-code-and-interface.patch
* mm-slub-restore-the-original-intention-of-prefetch_freepointer.patch
* mm-convert-return-type-of-handle_mm_fault-caller-to-vm_fault_t.patch
* mm-skip-invalid-pages-block-at-a-time-in-zero_resv_unresv.patch
* thp-use-mm_file_counter-to-determine-update-which-rss-counter.patch
* tools-modifying-page-types-to-include-shared-map-counts.patch
* tools-adding-support-for-idle-page-tracking-to-tool.patch
* mm-page_alloc-actually-ignore-mempolicies-for-high-priority-allocations.patch
* shmem-use-monotonic-time-for-i_generation.patch
* mm-page_ext-drop-definition-of-unused-page_ext_debug_poison.patch
* mm-page_ext-constify-lookup_page_ext-argument.patch
* mm-condense-scan_control.patch
* 
mm-mempool-remove-unused-argument-in-kasan_unpoison_element-and-remove_element.patch
* mm-thp-register-mm-for-khugepaged-when-merging-vma-for-shmem-v3.patch
* mm-thp-inc-counter-for-collapsed-shmem-thp.patch
* mpage-add-argument-structure-for-do_mpage_readpage.patch
* mpage-mpage_readpages-should-submit-io-as-read-ahead.patch
* btrfs-readpages-should-submit-io-as-read-ahead.patch
* ext4-readpages-should-submit-io-as-read-ahead.patch
* mm-clear_huge_page-move-order-algorithm-into-a-separate-function.patch
* mm-huge-page-copy-target-sub-page-last-when-copy-huge-page.patch
* mm-hugetlbfs-rename-address-to-haddr-in-hugetlb_cow.patch
*

Re: Crash in MM code in v4.4.y, v4.9.y with TRANSPARENT_HUGEPAGE enabledg

On Fri, Aug 17, 2018 at 03:39:07PM -0700, Andi Kleen wrote:
> On Fri, Aug 17, 2018 at 03:27:33PM -0700, Guenter Roeck wrote:
> > Hi,
> > 
> > the following crash is seen in v4.4.148, v4.4.149, v4.9.120, and v4.9.121
> > with CONFIG_TRANSPARENT_HUGEPAGE=y, CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y.
> 
> Just to confirm, it's not in mainline right? So only in backports?
> 

I have only seen it in v.4.4.y and v4.9.y. v4.14.y does not seem to be
affected.

> There's also a report for 4.17 in
> 
>  https://bugzilla.redhat.com/show_bug.cgi?id=1618792
> 
This is a different traceback, so it is most likely a different
problem.

I did not test v4.17.y. I'll do that (and v4.18.y, and mainline)
for completeness tonight.

Guenter

Re: Crash in MM code in v4.4.y, v4.9.y with TRANSPARENT_HUGEPAGE enabledg

On Fri, Aug 17, 2018 at 03:39:07PM -0700, Andi Kleen wrote:
> On Fri, Aug 17, 2018 at 03:27:33PM -0700, Guenter Roeck wrote:
> > Hi,
> > 
> > the following crash is seen in v4.4.148, v4.4.149, v4.9.120, and v4.9.121
> > with CONFIG_TRANSPARENT_HUGEPAGE=y, CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y.
> 
> Just to confirm, it's not in mainline right? So only in backports?
> 

I have only seen it in v.4.4.y and v4.9.y. v4.14.y does not seem to be
affected.

> There's also a report for 4.17 in
> 
>  https://bugzilla.redhat.com/show_bug.cgi?id=1618792
> 
This is a different traceback, so it is most likely a different
problem.

I did not test v4.17.y. I'll do that (and v4.18.y, and mainline)
for completeness tonight.

Guenter

Re: Crash in MM code in v4.4.y, v4.9.y with TRANSPARENT_HUGEPAGE enabledg

On Fri, Aug 17, 2018 at 03:27:33PM -0700, Guenter Roeck wrote:
> Hi,
> 
> the following crash is seen in v4.4.148, v4.4.149, v4.9.120, and v4.9.121
> with CONFIG_TRANSPARENT_HUGEPAGE=y, CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y.

Just to confirm, it's not in mainline right? So only in backports?

There's also a report for 4.17 in

 https://bugzilla.redhat.com/show_bug.cgi?id=1618792

(was trying to reproduce that, but not successfull so far)


-Andi

Re: Crash in MM code in v4.4.y, v4.9.y with TRANSPARENT_HUGEPAGE enabledg

On Fri, Aug 17, 2018 at 03:27:33PM -0700, Guenter Roeck wrote:
> Hi,
> 
> the following crash is seen in v4.4.148, v4.4.149, v4.9.120, and v4.9.121
> with CONFIG_TRANSPARENT_HUGEPAGE=y, CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y.

Just to confirm, it's not in mainline right? So only in backports?

There's also a report for 4.17 in

 https://bugzilla.redhat.com/show_bug.cgi?id=1618792

(was trying to reproduce that, but not successfull so far)


-Andi

Crash in MM code in v4.4.y, v4.9.y with TRANSPARENT_HUGEPAGE enabled

Hi,

the following crash is seen in v4.4.148, v4.4.149, v4.9.120, and v4.9.121
with CONFIG_TRANSPARENT_HUGEPAGE=y, CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y.

[6.649970] random: crng init done
[6.689002] BUG: unable to handle kernel paging request at eafffa1a0020
[6.689082] IP: [] page_remove_rmap+0x10/0x230
[6.689082] PGD 0 [6.689082] 
[6.689082] Oops:  [#1] SMP
[6.689082] Modules linked in:
[6.689082] CPU: 3 PID: 1132 Comm: mmtest Not tainted 4.9.121 #16
[6.689082] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org 04/01/204
[6.689082] task: 88017a558c40 task.stack: c97a8000
[6.689082] RIP: 0010:[]  [] 
page_remove_rmap+0x10/0x230
[6.689082] RSP: 0018:c97abc18  EFLAGS: 0296
[6.689082] RAX: ea0005e58000 RBX: eafffa1a RCX: 2020
[6.689082] RDX: 3fe0 RSI: 0001 RDI: eafffa1a
[6.689082] RBP: c97abc38 R08:  R09: 2080
[6.689082] R10: ea0005e51ec0 R11:  R12: eafffa1a
[6.689082] R13: c97abdc0 R14: 880179426808 R15: c97abdc0
[6.689082] FS:  () GS:88017fd8() 
knlGS:
[6.689082] CS:  0010 DS:  ES:  CR0: 80050033
[6.689082] CR2: eafffa1a0020 CR3: 00017a3f8000 CR4: 00340670
[6.689082] Stack:
[6.689082]  81138517 ea0005e50980 eafffa1a 
c97abdc0
[6.689082]  c97abc68 8118d52c 880179426808 
2020
[6.689082]  c97abdc0 c97abdc0 c97abd40 
8115e270
[6.689082] Call Trace:
[6.689082]  [] ? __alloc_pages_nodemask+0xd7/0x210
[6.689082]  [] zap_huge_pmd+0xec/0x2a0
[6.689082]  [] unmap_page_range+0x7d0/0x8d0
[6.689082]  [] unmap_single_vma+0x54/0xd0
[6.689082]  [] unmap_vmas+0x4c/0xa0
[6.689082]  [] exit_mmap+0xa7/0x130
[6.689082]  [] ? __khugepaged_exit+0x6f/0x100
[6.689082]  [] mmput+0x38/0x100
[6.689082]  [] do_exit+0x25c/0xb10
[6.689082]  [] do_group_exit+0x3e/0xa0
[6.689082]  [] SyS_exit_group+0xf/0x10
[6.689082]  [] do_syscall_64+0x5c/0xc0
[6.689082]  [] entry_SYSCALL_64_after_swapgs+0x58/0xc6
[6.689082] Code: 77 ff ff ff eb b8 be 13 00 00 00 4c 89 e7 e8 d8 40 fe ff 
48 63 d3 eb b3 0f 1f 00 55 48 89 e5 41 55 41 54 53 48 
[6.689082] RIP  [] page_remove_rmap+0x10/0x230
[6.689082]  RSP 
[6.689082] CR2: eafffa1a0020
[6.689082] ---[ end trace 62ac9ace190510cd ]---
[6.689082] Fixing recursive fault but reboot is needed!

A test program to trigger the crash is attached, as are bisect results
and some additional information.

Upstream commit 19f5c49bbc3 ("x86/speculation/l1tf: Exempt zeroed PTEs
from inversion") does not fix the problem.

Many thanks to the syzcaller team for finding the problem and for providing
a reproducer.

Any help to track down the problem would be appreciated. This is out of my
league.

Thanks,
Guenter

---
#define _GNU_SOURCE

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main()
{
  syscall(__NR_mmap, 0x2000, 0x100, 3, 0x32, -1, 0);
  syscall(__NR_madvise, 0x20a93000, 0x4000, 0xe);
  syscall(__NR_mremap, 0x20a96000, 0x1000, 0x80, 3, 0x2013);
  syscall(__NR_sigaltstack, 0x20341000, 0x20ef9ff8);
  syscall(__NR_mprotect, 0x2000, 0x80, 0);
  return 0;
}

---
# bad: [93e02ae4200184bab43ce29966e895826a756a37] Linux 4.9.120
# good: [8f21ecb4249a0914aea08bef1befca9019a3b44b] Linux 4.9.119
git bisect start 'v4.9.120' 'v4.9.119'
# bad: [a0695af3406ae2a08184bd47a9e948fe6f9858b9] x86/KVM: Warn user if KVM is 
loaded SMT and L1TF CPU bug being present
git bisect bad a0695af3406ae2a08184bd47a9e948fe6f9858b9
# good: [1a4922e0f01d08a4789b1e17b195bc30bf234a3b] mm: x86: move 
_PAGE_SWP_SOFT_DIRTY from bit 7 to bit 1
git bisect good 1a4922e0f01d08a4789b1e17b195bc30bf234a3b
# bad: [e0439285c628dea71517a1e77cab805d9134f898] x86/cpu: Remove the pointless 
CPU printout
git bisect bad e0439285c628dea71517a1e77cab805d9134f898
# bad: [e3923475ebb1b503668dfdb3ba90e2ebd46931e6] x86/speculation/l1tf: Limit 
swap file size to MAX_PA/2
git bisect bad e3923475ebb1b503668dfdb3ba90e2ebd46931e6
# bad: [33182fe97add6e83c195e9d0f7297a6499563b52] x86/speculation/l1tf: Protect 
PROT_NONE PTEs against speculation
git bisect bad 33182fe97add6e83c195e9d0f7297a6499563b52
# good: [60712274887fcd4ad5eb8e01796022b6b202143c] x86/speculation/l1tf: 
Protect swap entries against L1TF
git bisect good 60712274887fcd4ad5eb8e01796022b6b202143c
# first bad commit: [33182fe97add6e83c195e9d0f7297a6499563b52]
# x86/speculation/l1tf: Protect PROT_NONE PTEs against speculation

---
qemu command line:

qemu-system-x86_64 \
-kernel arch/x86/boot/bzImage -M q35 -cpu Broadwell-noTSX \
-no-reboot -m 4G -smp 4 \
-drive

Crash in MM code in v4.4.y, v4.9.y with TRANSPARENT_HUGEPAGE enabled

Hi,

the following crash is seen in v4.4.148, v4.4.149, v4.9.120, and v4.9.121
with CONFIG_TRANSPARENT_HUGEPAGE=y, CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y.

[6.649970] random: crng init done
[6.689002] BUG: unable to handle kernel paging request at eafffa1a0020
[6.689082] IP: [] page_remove_rmap+0x10/0x230
[6.689082] PGD 0 [6.689082] 
[6.689082] Oops:  [#1] SMP
[6.689082] Modules linked in:
[6.689082] CPU: 3 PID: 1132 Comm: mmtest Not tainted 4.9.121 #16
[6.689082] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org 04/01/204
[6.689082] task: 88017a558c40 task.stack: c97a8000
[6.689082] RIP: 0010:[]  [] 
page_remove_rmap+0x10/0x230
[6.689082] RSP: 0018:c97abc18  EFLAGS: 0296
[6.689082] RAX: ea0005e58000 RBX: eafffa1a RCX: 2020
[6.689082] RDX: 3fe0 RSI: 0001 RDI: eafffa1a
[6.689082] RBP: c97abc38 R08:  R09: 2080
[6.689082] R10: ea0005e51ec0 R11:  R12: eafffa1a
[6.689082] R13: c97abdc0 R14: 880179426808 R15: c97abdc0
[6.689082] FS:  () GS:88017fd8() 
knlGS:
[6.689082] CS:  0010 DS:  ES:  CR0: 80050033
[6.689082] CR2: eafffa1a0020 CR3: 00017a3f8000 CR4: 00340670
[6.689082] Stack:
[6.689082]  81138517 ea0005e50980 eafffa1a 
c97abdc0
[6.689082]  c97abc68 8118d52c 880179426808 
2020
[6.689082]  c97abdc0 c97abdc0 c97abd40 
8115e270
[6.689082] Call Trace:
[6.689082]  [] ? __alloc_pages_nodemask+0xd7/0x210
[6.689082]  [] zap_huge_pmd+0xec/0x2a0
[6.689082]  [] unmap_page_range+0x7d0/0x8d0
[6.689082]  [] unmap_single_vma+0x54/0xd0
[6.689082]  [] unmap_vmas+0x4c/0xa0
[6.689082]  [] exit_mmap+0xa7/0x130
[6.689082]  [] ? __khugepaged_exit+0x6f/0x100
[6.689082]  [] mmput+0x38/0x100
[6.689082]  [] do_exit+0x25c/0xb10
[6.689082]  [] do_group_exit+0x3e/0xa0
[6.689082]  [] SyS_exit_group+0xf/0x10
[6.689082]  [] do_syscall_64+0x5c/0xc0
[6.689082]  [] entry_SYSCALL_64_after_swapgs+0x58/0xc6
[6.689082] Code: 77 ff ff ff eb b8 be 13 00 00 00 4c 89 e7 e8 d8 40 fe ff 
48 63 d3 eb b3 0f 1f 00 55 48 89 e5 41 55 41 54 53 48 
[6.689082] RIP  [] page_remove_rmap+0x10/0x230
[6.689082]  RSP 
[6.689082] CR2: eafffa1a0020
[6.689082] ---[ end trace 62ac9ace190510cd ]---
[6.689082] Fixing recursive fault but reboot is needed!

A test program to trigger the crash is attached, as are bisect results
and some additional information.

Upstream commit 19f5c49bbc3 ("x86/speculation/l1tf: Exempt zeroed PTEs
from inversion") does not fix the problem.

Many thanks to the syzcaller team for finding the problem and for providing
a reproducer.

Any help to track down the problem would be appreciated. This is out of my
league.

Thanks,
Guenter

---
#define _GNU_SOURCE

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main()
{
  syscall(__NR_mmap, 0x2000, 0x100, 3, 0x32, -1, 0);
  syscall(__NR_madvise, 0x20a93000, 0x4000, 0xe);
  syscall(__NR_mremap, 0x20a96000, 0x1000, 0x80, 3, 0x2013);
  syscall(__NR_sigaltstack, 0x20341000, 0x20ef9ff8);
  syscall(__NR_mprotect, 0x2000, 0x80, 0);
  return 0;
}

---
# bad: [93e02ae4200184bab43ce29966e895826a756a37] Linux 4.9.120
# good: [8f21ecb4249a0914aea08bef1befca9019a3b44b] Linux 4.9.119
git bisect start 'v4.9.120' 'v4.9.119'
# bad: [a0695af3406ae2a08184bd47a9e948fe6f9858b9] x86/KVM: Warn user if KVM is 
loaded SMT and L1TF CPU bug being present
git bisect bad a0695af3406ae2a08184bd47a9e948fe6f9858b9
# good: [1a4922e0f01d08a4789b1e17b195bc30bf234a3b] mm: x86: move 
_PAGE_SWP_SOFT_DIRTY from bit 7 to bit 1
git bisect good 1a4922e0f01d08a4789b1e17b195bc30bf234a3b
# bad: [e0439285c628dea71517a1e77cab805d9134f898] x86/cpu: Remove the pointless 
CPU printout
git bisect bad e0439285c628dea71517a1e77cab805d9134f898
# bad: [e3923475ebb1b503668dfdb3ba90e2ebd46931e6] x86/speculation/l1tf: Limit 
swap file size to MAX_PA/2
git bisect bad e3923475ebb1b503668dfdb3ba90e2ebd46931e6
# bad: [33182fe97add6e83c195e9d0f7297a6499563b52] x86/speculation/l1tf: Protect 
PROT_NONE PTEs against speculation
git bisect bad 33182fe97add6e83c195e9d0f7297a6499563b52
# good: [60712274887fcd4ad5eb8e01796022b6b202143c] x86/speculation/l1tf: 
Protect swap entries against L1TF
git bisect good 60712274887fcd4ad5eb8e01796022b6b202143c
# first bad commit: [33182fe97add6e83c195e9d0f7297a6499563b52]
# x86/speculation/l1tf: Protect PROT_NONE PTEs against speculation

---
qemu command line:

qemu-system-x86_64 \
-kernel arch/x86/boot/bzImage -M q35 -cpu Broadwell-noTSX \
-no-reboot -m 4G -smp 4 \
-drive

Re: [Jfs-discussion] [PATCH] jfs: Expand usercopy whitelist for inline inode data

2018-08-17 Thread Kees Cook

On Thu, Aug 16, 2018 at 11:56 PM, Christian Kujau  wrote:
> On Fri, 3 Aug 2018, Kees Cook via Jfs-discussion wrote:
>> Bart Massey reported what turned out to be a usercopy whitelist false
>> positive in JFS when symlink contents exceeded 128 bytes. The inline
>> inode data (i_inline) is actually designed to overflow into the "extended
>
> So, this may be a stupid question, but: is there a way to disable this
> hardened usercopy thing with a boot option maybe?
>
> Apparently, CONFIG_HARDENED_USERCOPY_FALLBACK was disabled in Debian's
> 4.16.0-0.bpo.2-amd64 (4.16.16) kernels[0] and I have a VMware guest here
> that prints a BUG message (below) whenever a certain directory is being
> accesses. ls(1) is fine, but "ls -l" (i.e. with stat()) produces the splat
> below. And indeed, the target of one of the symlinks inside is 129
> characters long, and every attempt to stat it prints the splat below.
>
> Going back to 4.16.0-0.bpo.1-amd64 (4.16.5) helps, but I was wondering if
> there was a magic boot option to disable it while I wait for 4.18 to land
> in Debian? I booted with hardened_usercopy=off, but it doesn't seem to
> have an effect and the directory is still inaccessible.

Precisely this was just added upstream[1] for 4.19 but isn't available
in 4.16. It should be trivial to backport it, though, if Ben wants to
do that? (The JFS fix is in the 4.17 and 4.18 -stable trees now, too,
BTW.)

-Kees

[1] https://git.kernel.org/linus/b5cb15d9372a

-- 
Kees Cook
Pixel Security

Re: [Jfs-discussion] [PATCH] jfs: Expand usercopy whitelist for inline inode data

2018-08-17 Thread Kees Cook

On Thu, Aug 16, 2018 at 11:56 PM, Christian Kujau  wrote:
> On Fri, 3 Aug 2018, Kees Cook via Jfs-discussion wrote:
>> Bart Massey reported what turned out to be a usercopy whitelist false
>> positive in JFS when symlink contents exceeded 128 bytes. The inline
>> inode data (i_inline) is actually designed to overflow into the "extended
>
> So, this may be a stupid question, but: is there a way to disable this
> hardened usercopy thing with a boot option maybe?
>
> Apparently, CONFIG_HARDENED_USERCOPY_FALLBACK was disabled in Debian's
> 4.16.0-0.bpo.2-amd64 (4.16.16) kernels[0] and I have a VMware guest here
> that prints a BUG message (below) whenever a certain directory is being
> accesses. ls(1) is fine, but "ls -l" (i.e. with stat()) produces the splat
> below. And indeed, the target of one of the symlinks inside is 129
> characters long, and every attempt to stat it prints the splat below.
>
> Going back to 4.16.0-0.bpo.1-amd64 (4.16.5) helps, but I was wondering if
> there was a magic boot option to disable it while I wait for 4.18 to land
> in Debian? I booted with hardened_usercopy=off, but it doesn't seem to
> have an effect and the directory is still inaccessible.

Precisely this was just added upstream[1] for 4.19 but isn't available
in 4.16. It should be trivial to backport it, though, if Ben wants to
do that? (The JFS fix is in the 4.17 and 4.18 -stable trees now, too,
BTW.)

-Kees

[1] https://git.kernel.org/linus/b5cb15d9372a

-- 
Kees Cook
Pixel Security

Re: [Xen-devel] linux-next: manual merge of the akpm-current tree with the xen-tip tree

2018-08-17 Thread Boris Ostrovsky

On 08/15/2018 08:05 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 30 Jul 2018 19:02:10 +1000 Stephen Rothwell  
> wrote:
>> Today's linux-next merge of the akpm-current tree got a conflict in:
>>
>>   drivers/xen/gntdev.c
>>
>> between commit:
>>
>>   1d3145675538 ("xen/gntdev: Make private routines/structures accessible")
>>
>> from the xen-tip tree and commit:
>>
>>   aaefcabe9c25 ("mm, oom: distinguish blockable mode for mmu notifiers")
>>
>> from the akpm-current 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.
>>
>> -- 
>> Cheers,
>> Stephen Rothwell
>>
>> diff --cc drivers/xen/gntdev.c
>> index c866a62f766d,55b4f0e3f4d6..
>> --- a/drivers/xen/gntdev.c
>> +++ b/drivers/xen/gntdev.c
>> @@@ -479,7 -441,20 +479,20 @@@ static const struct vm_operations_struc
>>   
>>   /* -- */
>>   
>>  -static bool in_range(struct grant_map *map,
>> ++static bool in_range(struct gntdev_grant_map *map,
>> +  unsigned long start, unsigned long end)
>> + {
>> +if (!map->vma)
>> +return false;
>> +if (map->vma->vm_start >= end)
>> +return false;
>> +if (map->vma->vm_end <= start)
>> +return false;
>> + 
>> +return true;
>> + }
>> + 
>>  -static void unmap_if_in_range(struct grant_map *map,
>>  +static void unmap_if_in_range(struct gntdev_grant_map *map,
>>unsigned long start, unsigned long end)
>>   {
>>  unsigned long mstart, mend;
>> @@@ -503,15 -472,26 +510,26 @@@
>>  WARN_ON(err);
>>   }
>>   
>> - static void mn_invl_range_start(struct mmu_notifier *mn,
>> + static int mn_invl_range_start(struct mmu_notifier *mn,
>>  struct mm_struct *mm,
>> -unsigned long start, unsigned long end)
>> +unsigned long start, unsigned long end,
>> +bool blockable)
>>   {
>>  struct gntdev_priv *priv = container_of(mn, struct gntdev_priv, mn);
>>  -   struct grant_map *map;
>>  +   struct gntdev_grant_map *map;
>> +int ret = 0;
>> + 
>> +/* TODO do we really need a mutex here? */
>> +if (blockable)
>> +mutex_lock(>lock);
>> +else if (!mutex_trylock(>lock))
>> +return -EAGAIN;
>>   
>> -mutex_lock(>lock);
>>  list_for_each_entry(map, >maps, next) {
>> +if (in_range(map, start, end)) {
>> +ret = -EAGAIN;
>> +goto out_unlock;
>> +}
>>  unmap_if_in_range(map, start, end);


I think I mentioned this earlier --- this doesn't look right. Not the
conflict resolution but the original patch.

Should I send a patch against -next? Or -mm?


-boris





signature.asc
Description: OpenPGP digital signature

Re: [Xen-devel] linux-next: manual merge of the akpm-current tree with the xen-tip tree

2018-08-17 Thread Boris Ostrovsky

On 08/15/2018 08:05 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 30 Jul 2018 19:02:10 +1000 Stephen Rothwell  
> wrote:
>> Today's linux-next merge of the akpm-current tree got a conflict in:
>>
>>   drivers/xen/gntdev.c
>>
>> between commit:
>>
>>   1d3145675538 ("xen/gntdev: Make private routines/structures accessible")
>>
>> from the xen-tip tree and commit:
>>
>>   aaefcabe9c25 ("mm, oom: distinguish blockable mode for mmu notifiers")
>>
>> from the akpm-current 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.
>>
>> -- 
>> Cheers,
>> Stephen Rothwell
>>
>> diff --cc drivers/xen/gntdev.c
>> index c866a62f766d,55b4f0e3f4d6..
>> --- a/drivers/xen/gntdev.c
>> +++ b/drivers/xen/gntdev.c
>> @@@ -479,7 -441,20 +479,20 @@@ static const struct vm_operations_struc
>>   
>>   /* -- */
>>   
>>  -static bool in_range(struct grant_map *map,
>> ++static bool in_range(struct gntdev_grant_map *map,
>> +  unsigned long start, unsigned long end)
>> + {
>> +if (!map->vma)
>> +return false;
>> +if (map->vma->vm_start >= end)
>> +return false;
>> +if (map->vma->vm_end <= start)
>> +return false;
>> + 
>> +return true;
>> + }
>> + 
>>  -static void unmap_if_in_range(struct grant_map *map,
>>  +static void unmap_if_in_range(struct gntdev_grant_map *map,
>>unsigned long start, unsigned long end)
>>   {
>>  unsigned long mstart, mend;
>> @@@ -503,15 -472,26 +510,26 @@@
>>  WARN_ON(err);
>>   }
>>   
>> - static void mn_invl_range_start(struct mmu_notifier *mn,
>> + static int mn_invl_range_start(struct mmu_notifier *mn,
>>  struct mm_struct *mm,
>> -unsigned long start, unsigned long end)
>> +unsigned long start, unsigned long end,
>> +bool blockable)
>>   {
>>  struct gntdev_priv *priv = container_of(mn, struct gntdev_priv, mn);
>>  -   struct grant_map *map;
>>  +   struct gntdev_grant_map *map;
>> +int ret = 0;
>> + 
>> +/* TODO do we really need a mutex here? */
>> +if (blockable)
>> +mutex_lock(>lock);
>> +else if (!mutex_trylock(>lock))
>> +return -EAGAIN;
>>   
>> -mutex_lock(>lock);
>>  list_for_each_entry(map, >maps, next) {
>> +if (in_range(map, start, end)) {
>> +ret = -EAGAIN;
>> +goto out_unlock;
>> +}
>>  unmap_if_in_range(map, start, end);


I think I mentioned this earlier --- this doesn't look right. Not the
conflict resolution but the original patch.

Should I send a patch against -next? Or -mm?


-boris





signature.asc
Description: OpenPGP digital signature

[GIT PULL] hwspinlock updates for v4.19

The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:

  Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)

are available in the Git repository at:

  git://github.com/andersson/remoteproc tags/hwlock-v4.19

for you to fetch changes up to ddb34f480d1b8051bc18e6ff22e93a6c9a33f94f:

  hwspinlock: Fix incorrect return pointers (2018-07-30 20:54:51 -0700)


hwspinlock updates for v4.19

This introduces devres helpers and an API to request a lock by name,
then migrates the sprd SPI driver to use these.


Baolin Wang (8):
  hwspinlock: Add one new API to support getting a specific hwlock by the 
name
  hwspinlock: Add devm_xxx() APIs to request/free hwlock
  hwspinlock: Add devm_xxx() APIs to register/unregister one hwlock 
controller
  hwspinlock: Remove redundant config
  hwspinlock: Fix one comment mistake
  spi: sprd: Replace of_hwspin_lock_get_id() with 
of_hwspin_lock_get_id_byname()
  spi: sprd: Change to use devm_hwspin_lock_request_specific()
  hwspinlock: Fix incorrect return pointers

 drivers/hwspinlock/hwspinlock_core.c | 223 ++-
 drivers/spi/spi-sprd-adi.c   |  11 +-
 include/linux/hwspinlock.h   |  37 +-
 3 files changed, 262 insertions(+), 9 deletions(-)

[GIT PULL] rpmsg updates for v4.19

The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:

  Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)

are available in the Git repository at:

  git://github.com/andersson/remoteproc tags/rpmsg-v4.19

for you to fetch changes up to 00b645e0b4e4a3e5f8d88a4e9acf7e80045c34b4:

  rpmsg: Add compat ioctl for rpmsg char driver (2018-07-30 23:40:23 -0700)


rpmsg updates for v4.19

This fixes a few compile and kerneldoc warnings, allows rpmsg devices to
handle power domains, allow for labeling GLINK edges and supports compat
for rpmsg_char.


Arun Kumar Neelakantam (1):
  rpmsg: Add compat ioctl for rpmsg char driver

Chris Lew (2):
  dt-bindings: soc: qcom: Add label for GLINK bindings
  rpmsg: glink: Store edge name for glink device

Niklas Cassel (1):
  rpmsg: smd: Add missing include of sizes.h

Srinivas Kandagatla (4):
  rpmsg: glink: correctly annotate intent members
  rpmsg: glink: Fix various kerneldoc warnings.
  rpmsg: smd: fix kerneldoc warnings
  rpmsg: core: add support to power domains for devices

 .../devicetree/bindings/soc/qcom/qcom,glink.txt|  5 +++
 drivers/rpmsg/qcom_glink_native.c  | 51 +-
 drivers/rpmsg/qcom_smd.c   | 10 -
 drivers/rpmsg/rpmsg_char.c |  2 +
 drivers/rpmsg/rpmsg_core.c |  7 +++
 5 files changed, 53 insertions(+), 22 deletions(-)

[GIT PULL] hwspinlock updates for v4.19

The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:

  Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)

are available in the Git repository at:

  git://github.com/andersson/remoteproc tags/hwlock-v4.19

for you to fetch changes up to ddb34f480d1b8051bc18e6ff22e93a6c9a33f94f:

  hwspinlock: Fix incorrect return pointers (2018-07-30 20:54:51 -0700)


hwspinlock updates for v4.19

This introduces devres helpers and an API to request a lock by name,
then migrates the sprd SPI driver to use these.


Baolin Wang (8):
  hwspinlock: Add one new API to support getting a specific hwlock by the 
name
  hwspinlock: Add devm_xxx() APIs to request/free hwlock
  hwspinlock: Add devm_xxx() APIs to register/unregister one hwlock 
controller
  hwspinlock: Remove redundant config
  hwspinlock: Fix one comment mistake
  spi: sprd: Replace of_hwspin_lock_get_id() with 
of_hwspin_lock_get_id_byname()
  spi: sprd: Change to use devm_hwspin_lock_request_specific()
  hwspinlock: Fix incorrect return pointers

 drivers/hwspinlock/hwspinlock_core.c | 223 ++-
 drivers/spi/spi-sprd-adi.c   |  11 +-
 include/linux/hwspinlock.h   |  37 +-
 3 files changed, 262 insertions(+), 9 deletions(-)

[GIT PULL] rpmsg updates for v4.19

The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:

  Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)

are available in the Git repository at:

  git://github.com/andersson/remoteproc tags/rpmsg-v4.19

for you to fetch changes up to 00b645e0b4e4a3e5f8d88a4e9acf7e80045c34b4:

  rpmsg: Add compat ioctl for rpmsg char driver (2018-07-30 23:40:23 -0700)


rpmsg updates for v4.19

This fixes a few compile and kerneldoc warnings, allows rpmsg devices to
handle power domains, allow for labeling GLINK edges and supports compat
for rpmsg_char.


Arun Kumar Neelakantam (1):
  rpmsg: Add compat ioctl for rpmsg char driver

Chris Lew (2):
  dt-bindings: soc: qcom: Add label for GLINK bindings
  rpmsg: glink: Store edge name for glink device

Niklas Cassel (1):
  rpmsg: smd: Add missing include of sizes.h

Srinivas Kandagatla (4):
  rpmsg: glink: correctly annotate intent members
  rpmsg: glink: Fix various kerneldoc warnings.
  rpmsg: smd: fix kerneldoc warnings
  rpmsg: core: add support to power domains for devices

 .../devicetree/bindings/soc/qcom/qcom,glink.txt|  5 +++
 drivers/rpmsg/qcom_glink_native.c  | 51 +-
 drivers/rpmsg/qcom_smd.c   | 10 -
 drivers/rpmsg/rpmsg_char.c |  2 +
 drivers/rpmsg/rpmsg_core.c |  7 +++
 5 files changed, 53 insertions(+), 22 deletions(-)

[GIT PULL] remoteproc updates for v4.19

The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:

  Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)

are available in the Git repository at:

  git://github.com/andersson/remoteproc tags/rproc-v4.19

for you to fetch changes up to b2201ee554a5811f569f31280b0079e7d6177606:

  remoteproc/davinci: use the reset framework (2018-08-16 17:39:55 -0700)


remoteproc updates for v4.19

This adds support for pre-start and post-shutdown hooks for remoteproc
subdevices, refactors the Qualcomm Hexagon support to allow reuse
between several drivers, makes authentication in the MDT file loader
optional, migrates a few format strings to use %pK and migrates the
Davinci driver to use the reset framework.


Alex Elder (1):
  remoteproc: rename subdev probe and remove functions

Arnd Bergmann (2):
  remoteproc: qcom q6v5: fix modular build
  remoteproc: qcom: fix Q6V5_WCSS dependencies

Bartosz Golaszewski (1):
  remoteproc/davinci: use the reset framework

Bjorn Andersson (7):
  remoteproc: q6v5: Extract common resource handling
  remoteproc: qcom: adsp: Use common q6v5 helpers
  remoteproc: qcom: q6v5-pil: Use common q6v5 helpers
  remoteproc: Rename subdev functions to start/stop
  remoteproc: Make start and stop in subdev optional
  remoteproc: Make client initialize ops in rproc_subdev
  remoteproc: Introduce prepare and unprepare for subdevices

Loic Pallardy (2):
  remoteproc: replace "%p" with "%pK"
  remoteproc: st_slim: replace "%p" with "%pK"

Sibi Sankar (1):
  remoteproc: qcom: q6v5-pil: fix modem hang on SDM845 after axis2 clk 
unvote

Sricharan R (2):
  remoteproc: qcom: mdt_loader: Make the firmware authentication optional
  remoteproc: qcom: Introduce Hexagon V5 based WCSS driver

Suman Anna (2):
  remoteproc: Reset table_ptr in rproc_start() failure paths
  remoteproc/davinci: Mark error recovery as disabled

 .../devicetree/bindings/remoteproc/qcom,q6v5.txt   |   7 +-
 drivers/remoteproc/Kconfig |  23 +
 drivers/remoteproc/Makefile|   2 +
 drivers/remoteproc/da8xx_remoteproc.c  |  37 +-
 drivers/remoteproc/qcom_adsp_pil.c | 156 +-
 drivers/remoteproc/qcom_common.c   |  26 +-
 drivers/remoteproc/qcom_q6v5.c | 252 +
 drivers/remoteproc/qcom_q6v5.h |  46 ++
 drivers/remoteproc/qcom_q6v5_pil.c | 158 +-
 drivers/remoteproc/qcom_q6v5_wcss.c| 601 +
 drivers/remoteproc/qcom_sysmon.c   |   5 +-
 drivers/remoteproc/remoteproc_core.c   | 117 ++--
 drivers/remoteproc/remoteproc_debugfs.c|   4 +-
 drivers/remoteproc/remoteproc_virtio.c |   2 +-
 drivers/remoteproc/st_slim_rproc.c |   3 +-
 drivers/soc/qcom/mdt_loader.c  |  87 ++-
 include/linux/remoteproc.h |  19 +-
 include/linux/soc/qcom/mdt_loader.h|   4 +
 18 files changed, 1188 insertions(+), 361 deletions(-)
 create mode 100644 drivers/remoteproc/qcom_q6v5.c
 create mode 100644 drivers/remoteproc/qcom_q6v5.h
 create mode 100644 drivers/remoteproc/qcom_q6v5_wcss.c

[GIT PULL] remoteproc updates for v4.19

The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:

  Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)

are available in the Git repository at:

  git://github.com/andersson/remoteproc tags/rproc-v4.19

for you to fetch changes up to b2201ee554a5811f569f31280b0079e7d6177606:

  remoteproc/davinci: use the reset framework (2018-08-16 17:39:55 -0700)


remoteproc updates for v4.19

This adds support for pre-start and post-shutdown hooks for remoteproc
subdevices, refactors the Qualcomm Hexagon support to allow reuse
between several drivers, makes authentication in the MDT file loader
optional, migrates a few format strings to use %pK and migrates the
Davinci driver to use the reset framework.


Alex Elder (1):
  remoteproc: rename subdev probe and remove functions

Arnd Bergmann (2):
  remoteproc: qcom q6v5: fix modular build
  remoteproc: qcom: fix Q6V5_WCSS dependencies

Bartosz Golaszewski (1):
  remoteproc/davinci: use the reset framework

Bjorn Andersson (7):
  remoteproc: q6v5: Extract common resource handling
  remoteproc: qcom: adsp: Use common q6v5 helpers
  remoteproc: qcom: q6v5-pil: Use common q6v5 helpers
  remoteproc: Rename subdev functions to start/stop
  remoteproc: Make start and stop in subdev optional
  remoteproc: Make client initialize ops in rproc_subdev
  remoteproc: Introduce prepare and unprepare for subdevices

Loic Pallardy (2):
  remoteproc: replace "%p" with "%pK"
  remoteproc: st_slim: replace "%p" with "%pK"

Sibi Sankar (1):
  remoteproc: qcom: q6v5-pil: fix modem hang on SDM845 after axis2 clk 
unvote

Sricharan R (2):
  remoteproc: qcom: mdt_loader: Make the firmware authentication optional
  remoteproc: qcom: Introduce Hexagon V5 based WCSS driver

Suman Anna (2):
  remoteproc: Reset table_ptr in rproc_start() failure paths
  remoteproc/davinci: Mark error recovery as disabled

 .../devicetree/bindings/remoteproc/qcom,q6v5.txt   |   7 +-
 drivers/remoteproc/Kconfig |  23 +
 drivers/remoteproc/Makefile|   2 +
 drivers/remoteproc/da8xx_remoteproc.c  |  37 +-
 drivers/remoteproc/qcom_adsp_pil.c | 156 +-
 drivers/remoteproc/qcom_common.c   |  26 +-
 drivers/remoteproc/qcom_q6v5.c | 252 +
 drivers/remoteproc/qcom_q6v5.h |  46 ++
 drivers/remoteproc/qcom_q6v5_pil.c | 158 +-
 drivers/remoteproc/qcom_q6v5_wcss.c| 601 +
 drivers/remoteproc/qcom_sysmon.c   |   5 +-
 drivers/remoteproc/remoteproc_core.c   | 117 ++--
 drivers/remoteproc/remoteproc_debugfs.c|   4 +-
 drivers/remoteproc/remoteproc_virtio.c |   2 +-
 drivers/remoteproc/st_slim_rproc.c |   3 +-
 drivers/soc/qcom/mdt_loader.c  |  87 ++-
 include/linux/remoteproc.h |  19 +-
 include/linux/soc/qcom/mdt_loader.h|   4 +
 18 files changed, 1188 insertions(+), 361 deletions(-)
 create mode 100644 drivers/remoteproc/qcom_q6v5.c
 create mode 100644 drivers/remoteproc/qcom_q6v5.h
 create mode 100644 drivers/remoteproc/qcom_q6v5_wcss.c

Re: [PATCH 1/4] regulator: core: If consumers don't call regulator_set_load() assume max

On Tue 14 Aug 10:06 PDT 2018, Douglas Anderson wrote:

> Not all regulator consumers call regulator_set_load().  On some
> regulators (like on RPMh-regulator) this could be bad since the
> regulator framework will treat this as if consumer needs no load.
> It's much better to assume that a dumb client needs the maximum
> possible load so we get correctness first.
> 
> Signed-off-by: Douglas Anderson 

FWIW, we've had this problem on other devices as well; where the eMMC
won't operate properly unless the supply operates in HPM. We've worked
around this by specifying regulator-system-load for said regulators.

Only drawback with that is that we use DT to work around missing
features in the code. But at least the improved implementation will be
backwards compatible with existing DT.

Regards,
Bjorn

Re: [PATCH 1/4] regulator: core: If consumers don't call regulator_set_load() assume max

On Tue 14 Aug 10:06 PDT 2018, Douglas Anderson wrote:

> Not all regulator consumers call regulator_set_load().  On some
> regulators (like on RPMh-regulator) this could be bad since the
> regulator framework will treat this as if consumer needs no load.
> It's much better to assume that a dumb client needs the maximum
> possible load so we get correctness first.
> 
> Signed-off-by: Douglas Anderson 

FWIW, we've had this problem on other devices as well; where the eMMC
won't operate properly unless the supply operates in HPM. We've worked
around this by specifying regulator-system-load for said regulators.

Only drawback with that is that we use DT to work around missing
features in the code. But at least the improved implementation will be
backwards compatible with existing DT.

Regards,
Bjorn

Re: [GIT PULL] Please pull RDMA subsystem changes

On Fri, Aug 17, 2018 at 01:27:02PM -0700, Linus Torvalds wrote:
> On Fri, Aug 17, 2018 at 1:15 PM Jason Gunthorpe  wrote:
> >
> > We often have merge conflicts with RDMA, how do you prefer to get the
> > PR? I'm actually not very clear on this part of the process.
> 
> I  generally prefer the non-merged version, but with comments about
> the conflicts.
> 
> In fact, the really preferred model is generally to send me a
> non-merged pull request (say "tags/for-linus") but if the conflicts
> look even half-way nasty - or simply because you did the merge anyway
> just to get the proper diffstat because history is complex - mention
> that you have a merged branch for verification (say
> "branch/for-linus-merged").
> 
> When I get that kind of pull request, I'll just do the merge
> resolution myself, and after I've done it I'll generally then do
> 
>git checkout -b test-merge
>git pull  for-linus-merged
> 
> and then just compare the end result with my resolution as an extra
> verification step.
> 
> I may end up skipping the verification step if everything looks
> entirely trivial (and really, if you have no real reason for the
> pre-merged branch, don't bother even mentioning it even if you did it
> for the diffstat), but in practice whenever somebody does that, I have
> no reason not to just do that simple extra verification.
> 
> Most of the time the merges are exactly the same, possibly with
> whitespace or trivial ordering differences (things like Makefiles and
> Kconfig files often have add-add conflicts where the ordering really
> doesn't matter between two config options).
> 
> And then sometimes it shows that I missed something in my mmerge.
> 
> And sometimes it shows that  I do so many merges that I actually ended
> up noticing something that the submaintainer didn't.
> 
> So it can be uninteresting, and when it isn't uninteresting it can go
> either way, but so far for the people who do this, I've never been in
> the situation where I was *sorry* for the double merge and extra
> verification step.
> 
> Because when mis-merges happen (they are happily pretty rare) they are
> _so_ annoying and can be so hard to figure out later, that I'd rather
> spend a bit more time on the merge than have a dodgy one.

Thanks for the explanation. Doug and I will do this in future.

Jason

Re: [GIT PULL] Please pull RDMA subsystem changes

On Fri, Aug 17, 2018 at 01:27:02PM -0700, Linus Torvalds wrote:
> On Fri, Aug 17, 2018 at 1:15 PM Jason Gunthorpe  wrote:
> >
> > We often have merge conflicts with RDMA, how do you prefer to get the
> > PR? I'm actually not very clear on this part of the process.
> 
> I  generally prefer the non-merged version, but with comments about
> the conflicts.
> 
> In fact, the really preferred model is generally to send me a
> non-merged pull request (say "tags/for-linus") but if the conflicts
> look even half-way nasty - or simply because you did the merge anyway
> just to get the proper diffstat because history is complex - mention
> that you have a merged branch for verification (say
> "branch/for-linus-merged").
> 
> When I get that kind of pull request, I'll just do the merge
> resolution myself, and after I've done it I'll generally then do
> 
>git checkout -b test-merge
>git pull  for-linus-merged
> 
> and then just compare the end result with my resolution as an extra
> verification step.
> 
> I may end up skipping the verification step if everything looks
> entirely trivial (and really, if you have no real reason for the
> pre-merged branch, don't bother even mentioning it even if you did it
> for the diffstat), but in practice whenever somebody does that, I have
> no reason not to just do that simple extra verification.
> 
> Most of the time the merges are exactly the same, possibly with
> whitespace or trivial ordering differences (things like Makefiles and
> Kconfig files often have add-add conflicts where the ordering really
> doesn't matter between two config options).
> 
> And then sometimes it shows that I missed something in my mmerge.
> 
> And sometimes it shows that  I do so many merges that I actually ended
> up noticing something that the submaintainer didn't.
> 
> So it can be uninteresting, and when it isn't uninteresting it can go
> either way, but so far for the people who do this, I've never been in
> the situation where I was *sorry* for the double merge and extra
> verification step.
> 
> Because when mis-merges happen (they are happily pretty rare) they are
> _so_ annoying and can be so hard to figure out later, that I'd rather
> spend a bit more time on the merge than have a dodgy one.

Thanks for the explanation. Doug and I will do this in future.

Jason

[PATCH] ARM: dts: imx7s-warp: enable i2c3 device support

2018-08-17 Thread Pierre-Jean Texier

The WaRP7 has one mikroBUS socket on the back to plug click boards.
This patch allows to interact with some of these
i2c modules (EEPROM, RTC and so on).

Signed-off-by: Pierre-Jean Texier 
---
 arch/arm/boot/dts/imx7s-warp.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/imx7s-warp.dts b/arch/arm/boot/dts/imx7s-warp.dts
index fa390da..b3d0951 100644
--- a/arch/arm/boot/dts/imx7s-warp.dts
+++ b/arch/arm/boot/dts/imx7s-warp.dts
@@ -216,6 +216,13 @@
status = "okay";
 };
 
+ {
+   clock-frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c3>;
+   status = "okay";
+};
+
  {
clock-frequency = <10>;
pinctrl-names = "default";
@@ -346,6 +353,13 @@
>;
};
 
+   pinctrl_i2c3: i2c3grp {
+   fsl,pins = <
+   MX7D_PAD_I2C3_SDA__I2C3_SDA 0x407f
+   MX7D_PAD_I2C3_SCL__I2C3_SCL 0x407f
+   >;
+   };
+
pinctrl_i2c4: i2c4grp {
fsl,pins = <
MX7D_PAD_I2C4_SCL__I2C4_SCL 0x407f
-- 
2.7.4

[PATCH] ARM: dts: imx7s-warp: enable i2c3 device support

2018-08-17 Thread Pierre-Jean Texier

The WaRP7 has one mikroBUS socket on the back to plug click boards.
This patch allows to interact with some of these
i2c modules (EEPROM, RTC and so on).

Signed-off-by: Pierre-Jean Texier 
---
 arch/arm/boot/dts/imx7s-warp.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/imx7s-warp.dts b/arch/arm/boot/dts/imx7s-warp.dts
index fa390da..b3d0951 100644
--- a/arch/arm/boot/dts/imx7s-warp.dts
+++ b/arch/arm/boot/dts/imx7s-warp.dts
@@ -216,6 +216,13 @@
status = "okay";
 };
 
+ {
+   clock-frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c3>;
+   status = "okay";
+};
+
  {
clock-frequency = <10>;
pinctrl-names = "default";
@@ -346,6 +353,13 @@
>;
};
 
+   pinctrl_i2c3: i2c3grp {
+   fsl,pins = <
+   MX7D_PAD_I2C3_SDA__I2C3_SDA 0x407f
+   MX7D_PAD_I2C3_SCL__I2C3_SCL 0x407f
+   >;
+   };
+
pinctrl_i2c4: i2c4grp {
fsl,pins = <
MX7D_PAD_I2C4_SCL__I2C4_SCL 0x407f
-- 
2.7.4

Input: cros_ec_keyb: Remove check before calling pm_wakeup_event.

2018-08-17 Thread RaviChandra Sadineni

From: RaviChandra Sadineni 

hi Merek,

Unfortunately I could not get the device to boot even after using the 
exynos_defconfig. 
Can you please try this patch and see if this fixes the issue. If not can you 
enable the
debug logs and send me the logs.


Currently on every resume we check for mkbp events and notify the
clients. This helps in identifying the wakeup sources. But on devices
that do not support mkbp protocol, we might end up getting key state of
the keyboard in a loop and block the resume. Instead check for events only
if  mkbp is supported.

Signed-off-by: RaviChandra Sadineni 
---
 drivers/mfd/cros_ec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 65a9757a6d21..fe6f83766144 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -218,7 +218,8 @@ EXPORT_SYMBOL(cros_ec_suspend);
 
 static void cros_ec_report_events_during_suspend(struct cros_ec_device *ec_dev)
 {
-   while (cros_ec_get_next_event(ec_dev, NULL) > 0)
+   while (ec_dev->mkbp_event_supported &&
+  cros_ec_get_next_event(ec_dev, NULL) > 0)
blocking_notifier_call_chain(_dev->event_notifier,
 1, ec_dev);
 }
-- 
2.16.4

Input: cros_ec_keyb: Remove check before calling pm_wakeup_event.

2018-08-17 Thread RaviChandra Sadineni

From: RaviChandra Sadineni 

hi Merek,

Unfortunately I could not get the device to boot even after using the 
exynos_defconfig. 
Can you please try this patch and see if this fixes the issue. If not can you 
enable the
debug logs and send me the logs.


Currently on every resume we check for mkbp events and notify the
clients. This helps in identifying the wakeup sources. But on devices
that do not support mkbp protocol, we might end up getting key state of
the keyboard in a loop and block the resume. Instead check for events only
if  mkbp is supported.

Signed-off-by: RaviChandra Sadineni 
---
 drivers/mfd/cros_ec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 65a9757a6d21..fe6f83766144 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -218,7 +218,8 @@ EXPORT_SYMBOL(cros_ec_suspend);
 
 static void cros_ec_report_events_during_suspend(struct cros_ec_device *ec_dev)
 {
-   while (cros_ec_get_next_event(ec_dev, NULL) > 0)
+   while (ec_dev->mkbp_event_supported &&
+  cros_ec_get_next_event(ec_dev, NULL) > 0)
blocking_notifier_call_chain(_dev->event_notifier,
 1, ec_dev);
 }
-- 
2.16.4

Re: [GIT PULL] Please pull RDMA subsystem changes

On Fri, Aug 17, 2018 at 01:50:05PM -0700, Linus Torvalds wrote:
> On Fri, Aug 17, 2018 at 12:44 PM Linus Torvalds
>  wrote:
> >
> > Ok, everything but the max_sge thing was trivial. I just took yours.
> 
> Oh, and doing the full test compile, I notice there  are new warnings.
>
> That is *NOT* ok.

I expect to send you a pull request to remove all of this next
week. This is fall out from the SMC merge conflict reversion.

> The whole "x is deprecated" is not a useful warning. If you can't
> remove something, making it a reminder for yourself for later is not
> an acceptable excuse for  bothering everybody else with the warning,
> and possibly having other issues hidden because by the time there are
> expected warnings, people will start ignoring the unexpected ones too.
> 
> So "__deprecated" is for stuff that really isn't used any more, to
> catch possible new users. People have tried to use it for anything
> else, but it's always  been a much bigger pain than it is worth.

In this case it has become confusing what
CONFIG_ENABLE_WARN_DEPRECATED is for.

If the kernel is supposed to compile warning free with that config
set, then why have the config at all - it does nothing, by definition?

Would you like a patch to remove that CONFIG option?

Jason

Re: [GIT PULL] Please pull RDMA subsystem changes

On Fri, Aug 17, 2018 at 01:50:05PM -0700, Linus Torvalds wrote:
> On Fri, Aug 17, 2018 at 12:44 PM Linus Torvalds
>  wrote:
> >
> > Ok, everything but the max_sge thing was trivial. I just took yours.
> 
> Oh, and doing the full test compile, I notice there  are new warnings.
>
> That is *NOT* ok.

I expect to send you a pull request to remove all of this next
week. This is fall out from the SMC merge conflict reversion.

> The whole "x is deprecated" is not a useful warning. If you can't
> remove something, making it a reminder for yourself for later is not
> an acceptable excuse for  bothering everybody else with the warning,
> and possibly having other issues hidden because by the time there are
> expected warnings, people will start ignoring the unexpected ones too.
> 
> So "__deprecated" is for stuff that really isn't used any more, to
> catch possible new users. People have tried to use it for anything
> else, but it's always  been a much bigger pain than it is worth.

In this case it has become confusing what
CONFIG_ENABLE_WARN_DEPRECATED is for.

If the kernel is supposed to compile warning free with that config
set, then why have the config at all - it does nothing, by definition?

Would you like a patch to remove that CONFIG option?

Jason

Re: [GIT PULL] Please pull RDMA subsystem changes

On Fri, Aug 17, 2018 at 12:44 PM Linus Torvalds
 wrote:
>
> Ok, everything but the max_sge thing was trivial. I just took yours.

Oh, and doing the full test compile, I notice there  are new warnings.

That is *NOT* ok.

The whole "x is deprecated" is not a useful warning. If you can't
remove something, making it a reminder for yourself for later is not
an acceptable excuse for  bothering everybody else with the warning,
and possibly having other issues hidden because by the time there are
expected warnings, people will start ignoring the unexpected ones too.

So "__deprecated" is for stuff that really isn't used any more, to
catch possible new users. People have tried to use it for anything
else, but it's always  been a much bigger pain than it is worth.

I've considered just removing the whole deprecation infrastructure. It
has never really worked. Either its used, in which case deprecation
warnings only hide real issues, or it's not used, in which case the
function should just be removed.

   Linus

Re: [GIT PULL] Please pull RDMA subsystem changes