Re: [PATCH v3 bis 12/25] mtd: nand: use the mtd instance embedded in struct nand_chip

2015-12-09 Thread Boris Brezillon
Hi Brian,

On Tue, 8 Dec 2015 16:17:41 -0800
Brian Norris  wrote:

> 
> > diff --git a/drivers/mtd/nand/cmx270_nand.c b/drivers/mtd/nand/cmx270_nand.c
> > index 43bded6..84d027e 100644
> > --- a/drivers/mtd/nand/cmx270_nand.c
> > +++ b/drivers/mtd/nand/cmx270_nand.c
> > @@ -160,10 +160,8 @@ static int __init cmx270_init(void)
> > gpio_direction_input(GPIO_NAND_RB);
> >  
> > /* Allocate memory for MTD device structure and private data */
> > -   cmx270_nand_mtd = kzalloc(sizeof(struct mtd_info) +
> > - sizeof(struct nand_chip),
> > - GFP_KERNEL);
> > -   if (!cmx270_nand_mtd) {
> > +   this = kzalloc(sizeof(struct nand_chip), GFP_KERNEL);
> > +   if (!this) {
> > ret = -ENOMEM;
> > goto err_kzalloc;
> > }
> > @@ -175,8 +173,7 @@ static int __init cmx270_init(void)
> > goto err_ioremap;
> > }
> >  
> > -   /* Get pointer to private data */
> > -   this = (struct nand_chip *)(_nand_mtd[1]);
> > +   cmx270_nand_mtd = nand_to_mtd(this);
> 
> So, you make cmx270_nand_mtd no longer kzalloc()'d, but I still see the
> cmx270_init() function end with:
> 
> err_scan:
> iounmap(cmx270_nand_io);
> err_ioremap:
> kfree(cmx270_nand_mtd);  <- *** this! ***

Oh, crap.

> err_kzalloc:
> gpio_free(GPIO_NAND_RB);
> err_gpio_request:
>   gpio_free(GPIO_NAND_CS);
> 
>   return ret;
> 
> }
> 
> I have a feeling there's a failing in your coccinelle script somewhere.

These changes are not automated, because it's kind of hard to address
all the different cases where the following pattern is employed;

var = kzalloc(sizeof(struct mtd_info) +
  sizeof(struct nand_chip) + ..., ...);

Sometime var is an mtd_info pointer, sometime it's a nand_chip pointer
or directly a pointer to the private struct.

I'm pretty sure we could come up with a valid coccinelle script, but
given the number of drivers using this approach I'm not sure it is
worth it...

> 
> Given that I was only through 10 of 49 files changes, I think you might
> need to take a comb over your patch better.

I'll go over those changes one more time, but from my experience, these
kind of bugs are spotted more easily by people who didn't write the
code, so other reviews are more than welcome.

Also, as you suggested, I'll split the changes in several commits (one
per driver) so that you can pick them independently.

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v2 00/25] mtd: nand: refactor the NAND subsystem (part 1)

2015-12-09 Thread Boris Brezillon
Hi Brian,

On Tue, 8 Dec 2015 16:36:24 -0800
Brian Norris  wrote:

> Hi,
> 
> On Tue, Dec 01, 2015 at 12:02:57PM +0100, Boris Brezillon wrote:
> > Hello,
> > 
> > This huge series aims at clarifying the relationship between the mtd and
> > nand_chip structures and hiding NAND framework internals to NAND
> > controller drivers.
> > 
> > The first part of the series provide an mtd_to_nand() helper to hide the
> > way mtd and nand_chip are linked together.
> > 
> > The second part of the series embeds the mtd structure into the nand_chip
> > one so that NAND controller drivers don't have to bother allocating the
> > MTD device and linking it with the NAND chip.
> > 
> > The last part of the series hides accesses to the chip->priv field behind
> > two helper functions.
> > 
> > This allows removal of some of the boilerplate code done in all NAND
> > controller drivers, but most importantly, it unifies a bit the way NAND
> > chip structures are instantiated (even though we still have two different
> > kinds of drivers: those embedding the nand_chip struct into their private
> > nand chip representation, and those allocating two different structures
> > and linking them together with the chip->priv field).
> > 
> > As said in the title, this refactoring is only the first step. I plan to
> > rework the NAND controller / NAND chip separation for pretty much the same
> > reasons: clarifying the separation between the two concepts, and getting
> > rid of more boilerplate code in NAND controller drivers.
> > 
> > Stay tuned ;-).
> > 
> > Best Regards,
> > 
> > Boris
> > 
> > Changes since v1:
> > - dropped already applied patches
> > - fixed some typos
> > - manually fixed some modifications omitted by the coccinelle scripts
> > - manually reworked modifactions done by coccinelle scripts to improve
> >   readability and fix coding style issues
> > 
> > Boris Brezillon (25):
> >   ARM: nand: make use of mtd_to_nand() where appropriate
> 
> I've sent this (+ the introduction of mtd_to_nand()) in a pull request
> to arm-soc, as well as to l2-mtd.git.
> 
> >   blackfin: nand: make use of mtd_to_nand() where appropriate
> >   cris: nand: make use of mtd_to_nand() where appropriate
> >   mips: nand: make use of mtd_to_nand() where appropriate
> 
> I've based these on v4.4-rc1 and brought them into l2-mtd.git, in case
> any arch/{blackfin,cris,mips}/ people want to pull them in too.
> 
> >   sh: nand: make use of mtd_to_nand() where appropriate
> >   mtd: nand: make use of mtd_to_nand() in NAND core code
> >   mtd: nand: make use of mtd_to_nand() in NAND drivers
> >   staging: mt29f_spinand: make use of mtd_to_nand()
> >   mtd: nand: embed an mtd_info structure into nand_chip
> >   mtd: nand: add nand_to_mtd() helper
> 
> Pulled the rest up to here into l2-mtd.git.

Okay, thanks.

> 
> >   coccinelle: nand: detect and correct drivers embedding an mtd_info
> > object
> 
> I believe Julia had comments on this. That probably would go through the
> kbuild tree in the end anyway (?).

Julia proposed to generate this script using sgen, so I guess this will
come later through a different tree.

> 
> >   mtd: nand: use the mtd instance embedded in struct nand_chip
> 
> There's still at least one problem in this patch (commented on the
> patch). It touches a lot of drivers, so any extra review would be great.

Yep, I think I'll resend the series and split the modification so that
you can pick changes independently (as you suggested a few days ago).

Anyway, reviews from other people would be much appreciated. As I said,
most of changes have been automated with coccinelle, but some of them
have been made manually done, and this is the case for all drivers using
the following pattern:

var = kzalloc(sizeof(struct mtd_info) +
  sizeof(struct nand_chip) + ... ,...);

because I failed to find a pattern common enough to match the cases I
had, and manually fixing them was easier for me...

> 
> >   mtd: nand: update the documentation to reflect framework changes
> >   staging: mt29f_spinand: use the mtd instance embedded in struct
> > nand_chip
> >   cris: nand: use the mtd instance embedded in struct nand_chip
> >   mtd: nand: update mtd_to_nand()
> >   mtd: nand: remove useless mtd->priv = chip assignments
> >   cris: nand: remove useless mtd->priv = chip assignments
> >   staging: mt29f_spinand: remove useless mtd->priv = chip assignment
> >   mtd: nand: simplify nand_dt_init() usage
> >   mtd: nand: kill the chip->flash_node field
> >   mtd: nand: add helpers to access ->priv
> >   ARM: make use of nand_set/get_controller_data() helpers
> >   mtd: nand: make use of nand_set/get_controller_data() helpers
> >   staging: mt29f_spinand: make use of nand_set/get_controller_data()
> > helpers
> 
> All the rest look good to me. I'll wait until I get a good copy of patch
> 12 before taking them.

Sure.

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel 

Re: [PATCHv6 5/5] drm: bridge: anx78xx: Add anx78xx driver support by analogix.

2015-12-09 Thread Enric Balletbo Serra
Hi Dan,

Many thanks for your comments.

2015-12-07 9:09 GMT+01:00 Dan Carpenter :
> On Fri, Dec 04, 2015 at 09:35:07AM +0100, Enric Balletbo i Serra wrote:
>> +static int sp_wait_aux_op_finish(struct anx78xx *anx78xx)
>> +{
>> + u8 errcnt;
>> + u8 val;
>> + struct device *dev = >client->dev;
>> +
>> + errcnt = 150;
>> + while (errcnt--) {
>> + sp_reg_read(anx78xx, TX_P0, SP_DP_AUX_CH_CTRL2_REG, );
>> + if (!(val & SP_AUX_EN))
>> + break;
>> + usleep_range(2000, 4000);
>> + }
>> +
>> + if (!errcnt) {
>
> This is off by one.  It should be:
>
> while (--errcnt) {
> ...
> }
> if (errcnt == 0)
> return -EWHATEVER;
>
> Or:
>
> while (errcnt--) {
> ...
> }
> if (errcnt == -1)
> return -EWHATEVER;
>
> Also "errcnt" is a bad name, it should be retry_cnt or something (or
> maybe it actually is counting errors?).  Also -1 is never a correct
> error code, please change all the -1 returns to something better.
>

Ok, I renamed to retry_cnt and changed all the -1 values to something better.


>> + /* Buffer size of AUX CH is 16 */
>> + if (count > 16)
>> + return -1;
>
> Just make a define so that you don't need to add comments about why 16
> is correct.
>
> if (count > SIZE_AUX_CH)
> return -EINVAL;
>

Added a define

>> + errcnt = 10;
>> + while (errcnt--) {
>> + sp_reg_read(anx78xx, TX_P0, SP_DP_AUX_CH_CTRL2_REG, );
>> + if (!(val & SP_AUX_EN))
>> + break;
>> + usleep_range(1000, 2000);
>> + }
>> +
>> + if (!errcnt) {
>> + dev_err(dev,
>> + "failed to read DP AUX Channel Control Register 2\n");
>> + sp_reset_aux(anx78xx);
>> + return -1;
>> + }
>
> Off by one again.
>

Ack

>
>> +
>> + sp_reg_write(anx78xx, TX_P0, SP_AUX_ADDR_7_0_REG, SP_I2C_EXTRA_ADDR);
>> + sp_tx_aux_wr(anx78xx, offset);
>> + /* read 16 bytes (MOT = 1) */
>> + sp_tx_aux_rd(anx78xx, 0xf0 | DP_AUX_I2C_MOT | DP_AUX_I2C_READ);
>> +
>> + for (i = 0; i < 16; i++) {
>> + errcnt = 10;
>> + while (errcnt--) {
>> + sp_reg_read(anx78xx, TX_P0, SP_BUF_DATA_COUNT_REG,
>> + );
>> + if (val & SP_BUF_DATA_COUNT_MASK)
>> + break;
>> + usleep_range(2000, 4000);
>> + }
>> +
>> + if (!errcnt) {
>> + dev_err(dev,
>> + "failed to read DP Buffer Data Count 
>> Register\n");
>> + sp_reset_aux(anx78xx);
>> + return -1;
>> + }
>
> And here.
>

Ack

>> + errcnt = 10;
>> + while (errcnt--) {
>> + sp_reg_read(anx78xx, TX_P0, SP_DP_AUX_CH_CTRL2_REG, );
>> + if (!(val & SP_AUX_EN))
>> + break;
>> + usleep_range(1000, 2000);
>> + }
>> +
>> + if (!errcnt) {
>> + dev_err(dev,
>> + "failed to read DP AUX Channel Control Register 2\n");
>> + sp_reset_aux(anx78xx);
>> + return -1;
>> + }
>
> Here.
>

Ack

>
>> +
>> + return 0;
>> +}
>> +
>> +static int sp_edid_block_checksum(const u8 *raw_edid)
>> +{
>> + int i;
>> + u8 csum = 0;
>> +
>> + for (i = 0; i < EDID_LENGTH; i++)
>> + csum += raw_edid[i];
>> +
>> + return csum;
>> +}
>> +
>> +static int sp_tx_edid_read(struct anx78xx *anx78xx)
>> +{
>> + struct device *dev = >client->dev;
>> + u8 val, last_block, offset = 0;
>> + u8 buf[16];
>> + int i, j, count;
>> +
>> + sp_tx_edid_read_initial(anx78xx);
>> + sp_reg_write(anx78xx, TX_P0, SP_DP_AUX_CH_CTRL1_REG, 0x04);
>> + sp_reg_set_bits(anx78xx, TX_P0, SP_DP_AUX_CH_CTRL2_REG,
>> + SP_AUX_EN | SP_ADDR_ONLY);
>> +
>> + if (sp_wait_aux_op_finish(anx78xx))
>> + return -1;
>> +
>> + sp_addronly_set(anx78xx, false);
>> +
>> + /* Read the number of blocks */
>> + sp_tx_aux_wr(anx78xx, 0x7e);
>> + sp_tx_aux_rd(anx78xx, DP_AUX_I2C_READ);
>> + sp_reg_read(anx78xx, TX_P0, SP_DP_BUF_DATA0_REG, _block);
>> + dev_dbg(dev, "last EDID block is %d\n", last_block);
>> +
>> + /* FIXME: Why not just cap to 3 if the reported value is >3 */
>> + if (last_block > 3)
>> + last_block = 1;
>> +
>> + /* for every block */
>> + for (count = 0; count <= last_block; count++) {
>> + switch (count) {
>> + case 0:
>> + case 1:
>> + for (i = 0; i < 8; i++) {
>> + offset = (i + count * 8) * 16;
>> + if (sp_edid_read(anx78xx, offset, buf))
>> +  

Call to confirm !!

2015-12-09 Thread UNITED NATIONS PAYMENT NOTIFICATION
WESTERN UNION MONEY TRANSFER 
ITALY PAY-OUT CENTER 

Dear Western Union Beneficiary,

UNITED NATIONS PAYMENT NOTIFICATION. 

We wish to inform you that the United Nations (UN) has authorized us to remit 
to you a total amount of $500,000.00, (Five Hundred Thousand United States 
Dollars).  

Your Cash prize was paid out to us by the United Nations, and they have 
successfully succeeded in depositing your whole funds with us Here at Western 
Union Italy. 

They have now ordered us to take full responsibility in the transfer process of 
your funds and thus commence the immediate remittance of your funds to you. 

Be duly informed that because of our Western Union transfer policy, your funds 
will be paid to you via our Western Union Daily Transfer limit of $4,600.00 
USD. This means that you will Continuously receive a daily amount of $4,600.00 
USD, and this amount Can be collected from any of our numerous Western Union 
outlets in your current location. 

To begin the claim process of your daily payment as stated above, kindly 
furnish us with the following; 

Full Name: 
Address: 
Phone Number: 

Upon the receipt of the above mentioned details, your first transaction will be 
activated and we shall then Proceed to provide you with the Money Transfer 
Control Number (MTCN) for the First installment and we will continue to email 
you others after 12 hours of Receiving each payment. 

For more information on your payment status; 

Contact Person
Elena Paciotti For
Dario Pellizzari

OR call our 24 hours Helpline @ +39 389 230 3166, for any inquiries on the 
above message. 

Yours truly, 

Elena Paciotti

For: Western Union Italy. 
WESTERN UNION... Over 380,000 Outlets Worldwide
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 172/182] staging: vme: use gpiochip data pointer

2015-12-09 Thread Linus Walleij
This makes the driver use the data pointer added to the gpio_chip
to store a pointer to the state container instead of relying on
container_of().

Cc: Greg Kroah-Hartman 
Cc: Martyn Welch 
Cc: Manohar Vanga 
Cc: de...@driverdev.osuosl.org
Signed-off-by: Linus Walleij 
---
Greg, please ACK this so I can take this through the GPIO tree.
---
 drivers/staging/vme/devices/vme_pio2_gpio.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/vme/devices/vme_pio2_gpio.c 
b/drivers/staging/vme/devices/vme_pio2_gpio.c
index 77901b345a71..a2b740ab7ffe 100644
--- a/drivers/staging/vme/devices/vme_pio2_gpio.c
+++ b/drivers/staging/vme/devices/vme_pio2_gpio.c
@@ -17,7 +17,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
@@ -25,16 +25,11 @@
 
 static const char driver_name[] = "pio2_gpio";
 
-static struct pio2_card *gpio_to_pio2_card(struct gpio_chip *chip)
-{
-   return container_of(chip, struct pio2_card, gc);
-}
-
 static int pio2_gpio_get(struct gpio_chip *chip, unsigned int offset)
 {
u8 reg;
int retval;
-   struct pio2_card *card = gpio_to_pio2_card(chip);
+   struct pio2_card *card = gpiochip_get_data(chip);
 
if ((card->bank[PIO2_CHANNEL_BANK[offset]].config == OUTPUT) |
(card->bank[PIO2_CHANNEL_BANK[offset]].config == NOFIT)) {
@@ -72,7 +67,7 @@ static void pio2_gpio_set(struct gpio_chip *chip, unsigned 
int offset,
 {
u8 reg;
int retval;
-   struct pio2_card *card = gpio_to_pio2_card(chip);
+   struct pio2_card *card = gpiochip_get_data(chip);
 
if ((card->bank[PIO2_CHANNEL_BANK[offset]].config == INPUT) |
(card->bank[PIO2_CHANNEL_BANK[offset]].config == NOFIT)) {
@@ -102,7 +97,7 @@ static void pio2_gpio_set(struct gpio_chip *chip, unsigned 
int offset,
 static int pio2_gpio_dir_in(struct gpio_chip *chip, unsigned offset)
 {
int data;
-   struct pio2_card *card = gpio_to_pio2_card(chip);
+   struct pio2_card *card = gpiochip_get_data(chip);
 
if ((card->bank[PIO2_CHANNEL_BANK[offset]].config == OUTPUT) |
(card->bank[PIO2_CHANNEL_BANK[offset]].config == NOFIT)) {
@@ -121,7 +116,7 @@ static int pio2_gpio_dir_in(struct gpio_chip *chip, 
unsigned offset)
 static int pio2_gpio_dir_out(struct gpio_chip *chip, unsigned offset, int 
value)
 {
int data;
-   struct pio2_card *card = gpio_to_pio2_card(chip);
+   struct pio2_card *card = gpiochip_get_data(chip);
 
if ((card->bank[PIO2_CHANNEL_BANK[offset]].config == INPUT) |
(card->bank[PIO2_CHANNEL_BANK[offset]].config == NOFIT)) {
@@ -207,7 +202,7 @@ int pio2_gpio_init(struct pio2_card *card)
card->gc.set = pio2_gpio_set;
 
/* This function adds a memory mapped GPIO chip */
-   retval = gpiochip_add(&(card->gc));
+   retval = gpiochip_add_data(&(card->gc), card);
if (retval) {
dev_err(>vdev->dev, "Unable to register GPIO\n");
kfree(card->gc.label);
-- 
2.4.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH RESEND v3 02/11] fsl-mc: msi: Added FSL-MC-specific member to the msi_desc's union

2015-12-09 Thread Marc Zyngier
On 24/11/15 22:31, J. German Rivera wrote:
> FSL-MC is a bus type different from PCI and platform, so it needs
> its own member in the msi_desc's union.
> 
> Signed-off-by: J. German Rivera 

Acked-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny...
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] staging: unisys: visorchipset.c fixed spacing around operator

2015-12-09 Thread Bhaktipriya Shridhar
This patch fixes checkpatch.pl warning for visorchipset.c

CHECK: spaces preferred around that '*' (ctx:VxV)
+#define MAX_CONTROLVM_PAYLOAD_BYTES (1024*128)

Signed-off-by: Bhaktipriya Shridhar 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 07594f4..435291b 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -43,7 +43,7 @@
 #define POLLJIFFIES_CONTROLVMCHANNEL_FAST   1
 #define POLLJIFFIES_CONTROLVMCHANNEL_SLOW 100
 
-#define MAX_CONTROLVM_PAYLOAD_BYTES (1024*128)
+#define MAX_CONTROLVM_PAYLOAD_BYTES (1024 * 128)
 
 #define VISORCHIPSET_MMAP_CONTROLCHANOFFSET0x
 
-- 
2.1.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH RESEND v3 04/11] staging: fsl-mc: Added GICv3-ITS support for FSL-MC MSIs

2015-12-09 Thread Marc Zyngier
On 24/11/15 22:31, J. German Rivera wrote:
> Added platform-specific MSI support layer for FSL-MC devices.
> 
> Signed-off-by: J. German Rivera 
> ---
> CHANGE HISTORY
> 
> Changes in v3: none
> 
> Changes in v2: none
> 
>  drivers/staging/fsl-mc/bus/Makefile|   1 +
>  .../staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c | 127 
> +
>  drivers/staging/fsl-mc/include/mc-private.h|   4 +
>  3 files changed, 132 insertions(+)
>  create mode 100644 drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
> 
> diff --git a/drivers/staging/fsl-mc/bus/Makefile 
> b/drivers/staging/fsl-mc/bus/Makefile
> index a5f2ba4..e731517 100644
> --- a/drivers/staging/fsl-mc/bus/Makefile
> +++ b/drivers/staging/fsl-mc/bus/Makefile
> @@ -14,5 +14,6 @@ mc-bus-driver-objs := mc-bus.o \
> dprc-driver.o \
> mc-allocator.o \
> mc-msi.o \
> +   irq-gic-v3-its-fsl-mc-msi.o \
> dpmcp.o \
> dpbp.o
> diff --git a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c 
> b/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
> new file mode 100644
> index 000..5319afa
> --- /dev/null
> +++ b/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
> @@ -0,0 +1,127 @@
> +/*
> + * Freescale Management Complex (MC) bus driver MSI support
> + *
> + * Copyright (C) 2015 Freescale Semiconductor, Inc.
> + * Author: German Rivera 
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include "../include/mc-private.h"
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "../include/mc-sys.h"
> +#include "dprc-cmd.h"
> +
> +static struct irq_chip its_msi_irq_chip = {
> + .name = "fsl-mc-bus-msi",
> + .irq_mask = irq_chip_mask_parent,
> + .irq_unmask = irq_chip_unmask_parent,
> + .irq_eoi = irq_chip_eoi_parent,
> + .irq_set_affinity = msi_domain_set_affinity
> +};
> +
> +static int its_fsl_mc_msi_prepare(struct irq_domain *msi_domain,
> +   struct device *dev,
> +   int nvec, msi_alloc_info_t *info)
> +{
> + u32 its_dev_id;
> + struct fsl_mc_device *mc_bus_dev = to_fsl_mc_device(dev);
> + struct msi_domain_info *msi_info;
> +
> + if (WARN_ON(dev->bus != _mc_bus_type))
> + return -EINVAL;

Isn't that a bit late? You've already called to_fsl_mc_device()...

> +
> + if (WARN_ON(!(mc_bus_dev->flags & FSL_MC_IS_DPRC)))
> + return -EINVAL;
> +
> + /*
> +  * Set the device Id to be passed to the GIC-ITS:
> +  *
> +  * NOTE: This device id corresponds to the IOMMU stream ID
> +  * associated with the DPRC object (ICID).
> +  */
> + its_dev_id = mc_bus_dev->icid;
> + info->scratchpad[0].ul = its_dev_id;

You can probably get rid of the its_dev_id variable.

> + msi_info = msi_get_domain_info(msi_domain->parent);
> + return msi_info->ops->msi_prepare(msi_domain->parent, dev, nvec, info);
> +}
> +
> +static struct msi_domain_ops its_fsl_mc_msi_ops = {
> + .msi_prepare = its_fsl_mc_msi_prepare,
> +};
> +
> +static struct msi_domain_info its_fsl_mc_msi_domain_info = {
> + .flags  = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS),
> + .ops= _fsl_mc_msi_ops,
> + .chip   = _msi_irq_chip,
> +};
> +
> +static const struct of_device_id its_device_id[] = {
> + {   .compatible = "arm,gic-v3-its", },
> + {},
> +};
> +
> +int __init its_fsl_mc_msi_init(void)
> +{
> + struct device_node *np;
> + struct irq_domain *parent;
> + struct irq_domain *mc_msi_domain;
> +
> + for (np = of_find_matching_node(NULL, its_device_id); np;
> +  np = of_find_matching_node(np, its_device_id)) {
> + if (!of_property_read_bool(np, "msi-controller"))
> + continue;
> +
> + parent = irq_find_matching_host(np, DOMAIN_BUS_NEXUS);
> + if (!parent || !msi_get_domain_info(parent)) {
> + pr_err("%s: unable to locate ITS domain\n",
> +np->full_name);
> + continue;
> + }
> +
> + mc_msi_domain =
> + fsl_mc_msi_create_irq_domain(of_node_to_fwnode(np),
> +  _fsl_mc_msi_domain_info,
> +  parent);

Please keep both sides of the assignment on the same line.

> + if (!mc_msi_domain) {
> + pr_err("%s: unable to create fsl-mc domain\n",
> +np->full_name);
> + continue;
> + }
> +
> + 

Re: [PATCH RESEND v3 01/11] irqdomain: Added domain bus token DOMAIN_BUS_FSL_MC_MSI

2015-12-09 Thread Marc Zyngier
On 24/11/15 22:31, J. German Rivera wrote:
> Since an FSL-MC bus is a new bus type that is neither PCI nor
> PLATFORM, we need a new domain bus token to disambiguate the
> IRQ domain for FSL-MC MSIs.
> 
> Signed-off-by: J. German Rivera 

Acked-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny...
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH RESEND v3 03/11] staging: fsl-mc: Added generic MSI support for FSL-MC devices

2015-12-09 Thread Marc Zyngier
On 24/11/15 22:31, J. German Rivera wrote:
> Created an MSI domain for the fsl-mc bus-- including functions
> to create a domain, find a domain, alloc/free domain irqs, and
> bus specific overrides for domain and irq_chip ops.
> 
> Signed-off-by: J. German Rivera 
> ---
> CHANGE HISTORY
> 
> Changes in v3:
> - Addressed comments from Marc Zyngier:
>   * Added WARN_ON in fsl_mc_msi_set_desc to check that caller does
> not set set_desc
>   * Changed type of paddr in irq_cfg to be phys_addr_t
>   * Added WARN_ON in fsl_mc_msi_update_chip_op() to check that caller
> does not set irq_write_msi_msg
> 
> Changes in v2: none
> 
>  drivers/staging/fsl-mc/bus/Kconfig  |   1 +
>  drivers/staging/fsl-mc/bus/Makefile |   1 +
>  drivers/staging/fsl-mc/bus/mc-msi.c | 285 
> 
>  drivers/staging/fsl-mc/include/dprc.h   |   2 +-
>  drivers/staging/fsl-mc/include/mc-private.h |  17 ++
>  drivers/staging/fsl-mc/include/mc.h |  17 ++
>  6 files changed, 322 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/staging/fsl-mc/bus/mc-msi.c
> 

[...]

> diff --git a/drivers/staging/fsl-mc/bus/mc-msi.c 
> b/drivers/staging/fsl-mc/bus/mc-msi.c
> new file mode 100644
> index 000..d6ac465
> --- /dev/null
> +++ b/drivers/staging/fsl-mc/bus/mc-msi.c

[...]

> +int fsl_mc_find_msi_domain(struct device_node *mc_of_node,
> +struct irq_domain **mc_msi_domain)
> +{
> + struct device_node *msi_parent_node;
> + struct irq_domain *msi_domain;
> +
> + msi_parent_node = of_parse_phandle(mc_of_node, "msi-parent", 0);
> + if (!msi_parent_node) {
> + pr_err("msi-parent phandle missing for %s\n",
> +mc_of_node->full_name);
> + return -ENOENT;
> + }
> +
> + /*
> +  * Look up the fsl-mc MSI domain:
> +  */
> + msi_domain = irq_find_matching_host(msi_parent_node,
> + DOMAIN_BUS_FSL_MC_MSI);
> + if (!msi_domain) {
> + pr_err("Unable to find fsl-mc MSI domain for %s\n",
> +mc_of_node->full_name);
> +
> + return -ENOENT;
> + }
> +
> + *mc_msi_domain = msi_domain;
> + return 0;
> +}

We now have of_msi_get_domain() which does deal with this (and more). It
is probably worth investigating switching to it.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v7 4/7] PCI: Add fwnode_handle to pci_sysdata

2015-12-09 Thread Marc Zyngier
On 05/12/15 00:36, ja...@microsoft.com wrote:
> From: Jake Oshins 
> 
> This patch adds an fwnode_handle to struct pci_sysdata, which is
> used by the next patch in the series when trying to locate an
> IRQ domain associated with a root PCI bus.
> 
> Signed-off-by: Jake Oshins 
> ---
>  arch/x86/include/asm/pci.h | 15 +++
>  include/asm-generic/pci.h  |  4 
>  2 files changed, 19 insertions(+)
> 

[...]

> diff --git a/include/asm-generic/pci.h b/include/asm-generic/pci.h
> index f24bc51..4092886 100644
> --- a/include/asm-generic/pci.h
> +++ b/include/asm-generic/pci.h
> @@ -21,4 +21,8 @@ static inline int pci_get_legacy_ide_irq(struct pci_dev 
> *dev, int channel)
>  #define PCI_DMA_BUS_IS_PHYS  (1)
>  #endif
>  
> +#ifndef pci_root_bus_fwnode
> +#define pci_root_bus_fwnode(bus) ((void)(bus), NULL)
> +#endif
> +
>  #endif /* _ASM_GENERIC_PCI_H */
> 

This breaks at least arm64 (as you can see from the reply to patch #5, 
because it does have its own asm/pci.h. Instead, how about moving this 
to linux/pci.h, just after the include of asm/pci.h? I just gave it a 
go, and it seems to work nicely (the first hunk fixes the rest of the
arm64 compile issue):

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 8f3d056..c6369dd 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "pci.h"
 
diff --git a/include/asm-generic/pci.h b/include/asm-generic/pci.h
index 4092886..f24bc51 100644
--- a/include/asm-generic/pci.h
+++ b/include/asm-generic/pci.h
@@ -21,8 +21,4 @@ static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, 
int channel)
 #define PCI_DMA_BUS_IS_PHYS(1)
 #endif
 
-#ifndef pci_root_bus_fwnode
-#define pci_root_bus_fwnode(bus)   ((void)(bus), NULL)
-#endif
-
 #endif /* _ASM_GENERIC_PCI_H */
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 6ae25aa..b4144228 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1517,6 +1517,10 @@ static inline int pci_get_new_domain_nr(void) { return 
-ENOSYS; }
 
 #include 
 
+#ifndef pci_root_bus_fwnode
+#define pci_root_bus_fwnode(bus)   ((void)(bus), NULL)
+#endif
+
 /* these helpers provide future and backwards compatibility
  * for accessing popular PCI BAR info */
 #define pci_resource_start(dev, bar)   ((dev)->resource[(bar)].start)

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


RE: [PATCH v7 4/7] PCI: Add fwnode_handle to pci_sysdata

2015-12-09 Thread Jake Oshins
> -Original Message-
> From: Marc Zyngier [mailto:marc.zyng...@arm.com]
> Sent: Wednesday, December 9, 2015 8:51 AM
> To: Jake Oshins ; gre...@linuxfoundation.org; KY
> Srinivasan ; linux-ker...@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> vkuzn...@redhat.com; t...@linutronix.de; Haiyang Zhang
> ; bhelg...@google.com; linux-
> p...@vger.kernel.org
> Subject: Re: [PATCH v7 4/7] PCI: Add fwnode_handle to pci_sysdata
> 
> On 05/12/15 00:36, ja...@microsoft.com wrote:
> > From: Jake Oshins 
> >
> > This patch adds an fwnode_handle to struct pci_sysdata, which is
> > used by the next patch in the series when trying to locate an
> > IRQ domain associated with a root PCI bus.
> >
> > Signed-off-by: Jake Oshins 
> > ---
> >  arch/x86/include/asm/pci.h | 15 +++
> >  include/asm-generic/pci.h  |  4 
> >  2 files changed, 19 insertions(+)
> >
> 
> [...]
> 
> > diff --git a/include/asm-generic/pci.h b/include/asm-generic/pci.h
> > index f24bc51..4092886 100644
> > --- a/include/asm-generic/pci.h
> > +++ b/include/asm-generic/pci.h
> > @@ -21,4 +21,8 @@ static inline int pci_get_legacy_ide_irq(struct pci_dev
> *dev, int channel)
> >  #define PCI_DMA_BUS_IS_PHYS(1)
> >  #endif
> >
> > +#ifndef pci_root_bus_fwnode
> > +#define pci_root_bus_fwnode(bus)   ((void)(bus), NULL)
> > +#endif
> > +
> >  #endif /* _ASM_GENERIC_PCI_H */
> >
> 
> This breaks at least arm64 (as you can see from the reply to patch #5,
> because it does have its own asm/pci.h. Instead, how about moving this
> to linux/pci.h, just after the include of asm/pci.h? I just gave it a
> go, and it seems to work nicely (the first hunk fixes the rest of the
> arm64 compile issue):

Thank you.  I was just working through how to do that.  I lost a couple of days 
trying to figure out how to cross-compile for arm64 to check that any fix that 
I made actually worked.  (In the process, I've completely messed up my 
development machine.  Any pointers to the right strategy would be appreciated.)

-- Jake Oshins
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] staging: lustre/lustre/libcfs: Fix type mismatch reported by sparse

2015-12-09 Thread Niranjan Dighe
The third argument to function kportal_memhog_alloc is expected to
be gfp_t whereas the actual argument was unsigned int. Fix this by
explicitly typecasting to gfp_t

Signed-off-by: Niranjan Dighe 
---
 drivers/staging/lustre/lustre/libcfs/module.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/libcfs/module.c 
b/drivers/staging/lustre/lustre/libcfs/module.c
index 96d9d46..9c79f6e 100644
--- a/drivers/staging/lustre/lustre/libcfs/module.c
+++ b/drivers/staging/lustre/lustre/libcfs/module.c
@@ -268,7 +268,7 @@ static int libcfs_ioctl_int(struct cfs_psdev_file *pfile, 
unsigned long cmd,
/* XXX The ioc_flags is not GFP flags now, need to be 
fixed */
err = kportal_memhog_alloc(pfile->private_data,
   data->ioc_count,
-  data->ioc_flags);
+   (__force gfp_t)data->ioc_flags);
if (err != 0)
kportal_memhog_free(pfile->private_data);
}
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


RE: [lustre-devel] [PATCH] staging: lustre: add __user attributes to llite/file.c

2015-12-09 Thread Patrick Farrell
Greg just recently replied to a similar patch rejecting it.  I don't have his 
response handy, but I bet you can find it in the archives.  Briefly, this hides 
possible errors rather than fixing them.

From: lustre-devel [lustre-devel-boun...@lists.lustre.org] on behalf of Wim de 
With [nauxu...@wimdewith.com]
Sent: Tuesday, December 08, 2015 2:34 PM
To: oleg.dro...@intel.com; andreas.dil...@intel.com; gre...@linuxfoundation.org
Cc: de...@driverdev.osuosl.org; Wim de With; linux-ker...@vger.kernel.org; 
lustre-de...@lists.lustre.org
Subject: [lustre-devel] [PATCH] staging: lustre: add __user attributes to   
llite/file.c

This fixes the following sparse warnings:

drivers/staging/lustre/lustre/llite/file.c:1310:38:expected void const 
[noderef] *from
drivers/staging/lustre/lustre/llite/file.c:1310:38:got struct 
ll_recreate_obj *
drivers/staging/lustre/lustre/llite/file.c:1328:35: warning: incorrect type in 
argument 2 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:1328:35:expected void const 
[noderef] *from
drivers/staging/lustre/lustre/llite/file.c:1328:35:got struct lu_fid 
*
drivers/staging/lustre/lustre/llite/file.c:1475:35: warning: incorrect type in 
argument 2 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:1475:35:expected void const 
[noderef] *from
drivers/staging/lustre/lustre/llite/file.c:1475:35:got struct 
lov_user_md_v1 *
drivers/staging/lustre/lustre/llite/file.c:1500:35: warning: incorrect type in 
argument 2 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:1500:35:expected void const 
[noderef] *from
drivers/staging/lustre/lustre/llite/file.c:1500:35:got struct 
lov_user_md_v1 *lumv1p
drivers/staging/lustre/lustre/llite/file.c:1505:44: warning: incorrect type in 
argument 2 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:1505:44:expected void const 
[noderef] *from
drivers/staging/lustre/lustre/llite/file.c:1505:44:got struct 
lov_user_md_v3 *lumv3p
drivers/staging/lustre/lustre/llite/file.c:1516:17: warning: incorrect type in 
argument 1 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:1516:17:expected void const 
volatile [noderef] *
drivers/staging/lustre/lustre/llite/file.c:1516:17:got unsigned short 
*
drivers/staging/lustre/lustre/llite/file.c:1829:27: warning: incorrect type in 
argument 1 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:1829:27:expected void [noderef] 
*to
drivers/staging/lustre/lustre/llite/file.c:1829:27:got void *
drivers/staging/lustre/lustre/llite/file.c:2214:24: warning: incorrect type in 
argument 1 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:2214:24:expected void const 
volatile [noderef] *
drivers/staging/lustre/lustre/llite/file.c:2214:24:got int *
drivers/staging/lustre/lustre/llite/file.c:2221:21: warning: incorrect type in 
argument 1 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:2221:21:expected void const 
volatile [noderef] *
drivers/staging/lustre/lustre/llite/file.c:2221:21:got int *
drivers/staging/lustre/lustre/llite/file.c:2245:43: warning: incorrect type in 
argument 2 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:2245:43:expected void const 
[noderef] *from
drivers/staging/lustre/lustre/llite/file.c:2245:43:got char *
drivers/staging/lustre/lustre/llite/file.c:2275:24: warning: incorrect type in 
argument 1 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:2275:24:expected void const 
volatile [noderef] *
drivers/staging/lustre/lustre/llite/file.c:2275:24:got int *
drivers/staging/lustre/lustre/llite/file.c:2292:35: warning: incorrect type in 
argument 1 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:2292:35:expected void [noderef] 
*to
drivers/staging/lustre/lustre/llite/file.c:2292:35:got void *
drivers/staging/lustre/lustre/llite/file.c:2299:44: warning: incorrect type in 
argument 2 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:2299:44:expected void [noderef] 
*arg
drivers/staging/lustre/lustre/llite/file.c:2299:44:got void *
drivers/staging/lustre/lustre/llite/file.c:2304:43: warning: incorrect type in 
argument 2 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:2304:43:expected void const 
[noderef] *from
drivers/staging/lustre/lustre/llite/file.c:2304:43:got char *
drivers/staging/lustre/lustre/llite/file.c:2310:46: warning: incorrect type in 
argument 1 (different address spaces)
drivers/staging/lustre/lustre/llite/file.c:2310:46:expected void [noderef] 
*to
drivers/staging/lustre/lustre/llite/file.c:2310:46:got char *
drivers/staging/lustre/lustre/llite/file.c:2323:21: warning: incorrect type in 
argument 1 (different address spaces)

[PATCH v9 2/7] drivers:hv: Export hv_do_hypercall()

2015-12-09 Thread jakeo
From: Jake Oshins 

This patch exposes the function that hv_vmbus.ko uses to make hypercalls.
This is necessary for retargeting an interrupt when it is given a new
affinity and vector.

Signed-off-by: Jake Oshins 
---
 drivers/hv/hv.c   | 20 ++--
 drivers/hv/hyperv_vmbus.h |  2 +-
 include/linux/hyperv.h|  1 +
 3 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 6341be8..7a06933 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -89,9 +89,9 @@ static int query_hypervisor_info(void)
 }
 
 /*
- * do_hypercall- Invoke the specified hypercall
+ * hv_do_hypercall- Invoke the specified hypercall
  */
-static u64 do_hypercall(u64 control, void *input, void *output)
+u64 hv_do_hypercall(u64 control, void *input, void *output)
 {
u64 input_address = (input) ? virt_to_phys(input) : 0;
u64 output_address = (output) ? virt_to_phys(output) : 0;
@@ -132,6 +132,7 @@ static u64 do_hypercall(u64 control, void *input, void 
*output)
return hv_status_lo | ((u64)hv_status_hi << 32);
 #endif /* !x86_64 */
 }
+EXPORT_SYMBOL_GPL(hv_do_hypercall);
 
 #ifdef CONFIG_X86_64
 static cycle_t read_hv_clock_tsc(struct clocksource *arg)
@@ -315,7 +316,7 @@ int hv_post_message(union hv_connection_id connection_id,
 {
 
struct hv_input_post_message *aligned_msg;
-   u16 status;
+   u64 status;
 
if (payload_size > HV_MESSAGE_PAYLOAD_BYTE_COUNT)
return -EMSGSIZE;
@@ -329,11 +330,10 @@ int hv_post_message(union hv_connection_id connection_id,
aligned_msg->payload_size = payload_size;
memcpy((void *)aligned_msg->payload, payload, payload_size);
 
-   status = do_hypercall(HVCALL_POST_MESSAGE, aligned_msg, NULL)
-   & 0x;
+   status = hv_do_hypercall(HVCALL_POST_MESSAGE, aligned_msg, NULL);
 
put_cpu();
-   return status;
+   return status & 0x;
 }
 
 
@@ -343,13 +343,13 @@ int hv_post_message(union hv_connection_id connection_id,
  *
  * This involves a hypercall.
  */
-u16 hv_signal_event(void *con_id)
+int hv_signal_event(void *con_id)
 {
-   u16 status;
+   u64 status;
 
-   status = (do_hypercall(HVCALL_SIGNAL_EVENT, con_id, NULL) & 0x);
+   status = hv_do_hypercall(HVCALL_SIGNAL_EVENT, con_id, NULL);
 
-   return status;
+   return status & 0x;
 }
 
 static int hv_ce_set_next_event(unsigned long delta,
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 3782636..cc2fb53 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -582,7 +582,7 @@ extern int hv_post_message(union hv_connection_id 
connection_id,
 enum hv_message_type message_type,
 void *payload, size_t payload_size);
 
-extern u16 hv_signal_event(void *con_id);
+extern int hv_signal_event(void *con_id);
 
 extern int hv_synic_alloc(void);
 
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index fddb3e0..24d0b65 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -984,6 +984,7 @@ int vmbus_allocate_mmio(struct resource **new, struct 
hv_device *device_obj,
bool fb_overlap_ok);
 
 int vmbus_cpu_number_to_vp_number(int cpu_number);
+u64 hv_do_hypercall(u64 control, void *input, void *output);
 
 /**
  * VMBUS_DEVICE - macro used to describe a specific hyperv vmbus device
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v9 3/7] PCI: Make it possible to implement a PCI MSI IRQ Domain in a module.

2015-12-09 Thread jakeo
From: Jake Oshins 

The Linux kernel already has the concpet of IRQ domain, wherein a
component can expose a set of IRQs which are managed by a particular
interrupt controller chip or other subsystem. The PCI driver exposes
the notion of an IRQ domain for Message-Signaled Interrupts (MSI) from
PCI Express devices. This patch exposes the functions which are
necessary for making an MSI IRQ domain within a module.

Signed-off-by: Jake Oshins 
---
 arch/x86/include/asm/msi.h| 6 ++
 arch/x86/kernel/apic/msi.c| 8 +---
 arch/x86/kernel/apic/vector.c | 2 ++
 drivers/pci/msi.c | 4 
 kernel/irq/chip.c | 1 +
 kernel/irq/irqdomain.c| 4 
 6 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/msi.h b/arch/x86/include/asm/msi.h
index 93724cc..eb4b09b 100644
--- a/arch/x86/include/asm/msi.h
+++ b/arch/x86/include/asm/msi.h
@@ -1,7 +1,13 @@
 #ifndef _ASM_X86_MSI_H
 #define _ASM_X86_MSI_H
 #include 
+#include 
 
 typedef struct irq_alloc_info msi_alloc_info_t;
 
+int pci_msi_prepare(struct irq_domain *domain, struct device *dev, int nvec,
+   msi_alloc_info_t *arg);
+
+void pci_msi_set_desc(msi_alloc_info_t *arg, struct msi_desc *desc);
+
 #endif /* _ASM_X86_MSI_H */
diff --git a/arch/x86/kernel/apic/msi.c b/arch/x86/kernel/apic/msi.c
index 5f1feb6..ade2532 100644
--- a/arch/x86/kernel/apic/msi.c
+++ b/arch/x86/kernel/apic/msi.c
@@ -96,8 +96,8 @@ static irq_hw_number_t pci_msi_get_hwirq(struct 
msi_domain_info *info,
return arg->msi_hwirq;
 }
 
-static int pci_msi_prepare(struct irq_domain *domain, struct device *dev,
-  int nvec, msi_alloc_info_t *arg)
+int pci_msi_prepare(struct irq_domain *domain, struct device *dev, int nvec,
+   msi_alloc_info_t *arg)
 {
struct pci_dev *pdev = to_pci_dev(dev);
struct msi_desc *desc = first_pci_msi_entry(pdev);
@@ -113,11 +113,13 @@ static int pci_msi_prepare(struct irq_domain *domain, 
struct device *dev,
 
return 0;
 }
+EXPORT_SYMBOL_GPL(pci_msi_prepare);
 
-static void pci_msi_set_desc(msi_alloc_info_t *arg, struct msi_desc *desc)
+void pci_msi_set_desc(msi_alloc_info_t *arg, struct msi_desc *desc)
 {
arg->msi_hwirq = pci_msi_domain_calc_hwirq(arg->msi_dev, desc);
 }
+EXPORT_SYMBOL_GPL(pci_msi_set_desc);
 
 static struct msi_domain_ops pci_msi_domain_ops = {
.get_hwirq  = pci_msi_get_hwirq,
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index 861bc59..908cb37 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -29,6 +29,7 @@ struct apic_chip_data {
 };
 
 struct irq_domain *x86_vector_domain;
+EXPORT_SYMBOL_GPL(x86_vector_domain);
 static DEFINE_RAW_SPINLOCK(vector_lock);
 static cpumask_var_t vector_cpumask;
 static struct irq_chip lapic_controller;
@@ -66,6 +67,7 @@ struct irq_cfg *irqd_cfg(struct irq_data *irq_data)
 
return data ? >cfg : NULL;
 }
+EXPORT_SYMBOL_GPL(irqd_cfg);
 
 struct irq_cfg *irq_cfg(unsigned int irq)
 {
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 7eaa4c8..7a0df3f 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -257,6 +257,7 @@ void pci_msi_mask_irq(struct irq_data *data)
 {
msi_set_mask_bit(data, 1);
 }
+EXPORT_SYMBOL_GPL(pci_msi_mask_irq);
 
 /**
  * pci_msi_unmask_irq - Generic irq chip callback to unmask PCI/MSI interrupts
@@ -266,6 +267,7 @@ void pci_msi_unmask_irq(struct irq_data *data)
 {
msi_set_mask_bit(data, 0);
 }
+EXPORT_SYMBOL_GPL(pci_msi_unmask_irq);
 
 void default_restore_msi_irqs(struct pci_dev *dev)
 {
@@ -1126,6 +1128,7 @@ struct pci_dev *msi_desc_to_pci_dev(struct msi_desc *desc)
 {
return to_pci_dev(desc->dev);
 }
+EXPORT_SYMBOL(msi_desc_to_pci_dev);
 
 void *msi_desc_to_pci_sysdata(struct msi_desc *desc)
 {
@@ -1285,6 +1288,7 @@ struct irq_domain *pci_msi_create_irq_domain(struct 
fwnode_handle *fwnode,
domain->bus_token = DOMAIN_BUS_PCI_MSI;
return domain;
 }
+EXPORT_SYMBOL_GPL(pci_msi_create_irq_domain);
 
 /**
  * pci_msi_domain_alloc_irqs - Allocate interrupts for @dev in @domain
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 05e29de..5797909 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -950,6 +950,7 @@ void irq_chip_ack_parent(struct irq_data *data)
data = data->parent_data;
data->chip->irq_ack(data);
 }
+EXPORT_SYMBOL_GPL(irq_chip_ack_parent);
 
 /**
  * irq_chip_mask_parent - Mask the parent interrupt
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 22aa961..aa6ac44 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -60,6 +60,7 @@ struct fwnode_handle *irq_domain_alloc_fwnode(void *data)
fwid->fwnode.type = FWNODE_IRQCHIP;
return >fwnode;
 }
+EXPORT_SYMBOL_GPL(irq_domain_alloc_fwnode);
 
 /**
  * irq_domain_free_fwnode - Free a non-OF-backed fwnode_handle
@@ -77,6 +78,7 @@ void 

[PATCH v9 1/7] drivers:hv: Export a function that maps Linux CPU num onto Hyper-V proc num

2015-12-09 Thread jakeo
From: Jake Oshins 

This patch exposes the mapping between Linux CPU number and Hyper-V
virtual processor number. This is necessary because the hypervisor needs
to know which virtual processor to target when making a mapping in the
Interrupt Redirection Table in the I/O MMU.

Signed-off-by: Jake Oshins 
---
 drivers/hv/vmbus_drv.c | 17 +
 include/linux/hyperv.h |  2 ++
 2 files changed, 19 insertions(+)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index f19b6f7..c89d0e5 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1191,6 +1191,23 @@ int vmbus_allocate_mmio(struct resource **new, struct 
hv_device *device_obj,
 }
 EXPORT_SYMBOL_GPL(vmbus_allocate_mmio);
 
+/**
+ * vmbus_cpu_number_to_vp_number() - Map CPU to VP.
+ * @cpu_number: CPU number in Linux terms
+ *
+ * This function returns the mapping between the Linux processor
+ * number and the hypervisor's virtual processor number, useful
+ * in making hypercalls and such that talk about specific
+ * processors.
+ *
+ * Return: Virtual processor number in Hyper-V terms
+ */
+int vmbus_cpu_number_to_vp_number(int cpu_number)
+{
+   return hv_context.vp_index[cpu_number];
+}
+EXPORT_SYMBOL_GPL(vmbus_cpu_number_to_vp_number);
+
 static int vmbus_acpi_add(struct acpi_device *device)
 {
acpi_status result;
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 8fdc17b..fddb3e0 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -983,6 +983,8 @@ int vmbus_allocate_mmio(struct resource **new, struct 
hv_device *device_obj,
resource_size_t size, resource_size_t align,
bool fb_overlap_ok);
 
+int vmbus_cpu_number_to_vp_number(int cpu_number);
+
 /**
  * VMBUS_DEVICE - macro used to describe a specific hyperv vmbus device
  *
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v9 5/7] PCI: irqdomain: Look up IRQ domain by fwnode_handle

2015-12-09 Thread jakeo
From: Jake Oshins 

This patch adds a second way of finding an IRQ domain associated with
a root PCI bus.  After looking to see if one can be found through
the OF tree, it attempts to look up the IRQ domain through an
fwnode_handle stored in the pci_sysdata struct.

Signed-off-by: Jake Oshins 
---
 drivers/pci/probe.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 750f907..c6369dd 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -674,6 +674,20 @@ static struct irq_domain 
*pci_host_bridge_msi_domain(struct pci_bus *bus)
 */
d = pci_host_bridge_of_msi_domain(bus);
 
+#ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
+   /*
+* If no IRQ domain was found via the OF tree, try looking it up
+* directly through the fwnode_handle.
+*/
+   if (!d) {
+   struct fwnode_handle *fwnode = pci_root_bus_fwnode(bus);
+
+   if (fwnode)
+   d = irq_find_matching_fwnode(fwnode,
+DOMAIN_BUS_PCI_MSI);
+   }
+#endif
+
return d;
 }
 
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v9 6/7] drivers:hv: Define the channel type of Hyper-V PCI Express pass-through

2015-12-09 Thread jakeo
From: Jake Oshins 

This defines the channel type for PCI front-ends in Hyper-V VMs.

Signed-off-by: Jake Oshins 
---
 include/linux/hyperv.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 24d0b65..c9a9eed 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1141,6 +1141,17 @@ u64 hv_do_hypercall(u64 control, void *input, void 
*output);
}
 
 /*
+ * PCI Express Pass Through
+ * {44C4F61D--4400-9D52-802E27EDE19F}
+ */
+
+#define HV_PCIE_GUID \
+   .guid = { \
+   0x1D, 0xF6, 0xC4, 0x44, 0x44, 0x44, 0x00, 0x44, \
+   0x9D, 0x52, 0x80, 0x2E, 0x27, 0xED, 0xE1, 0x9F \
+   }
+
+/*
  * Common header for Hyper-V ICs
  */
 
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] Fixed coding style problems based on checkpatch.pl for goldfish_audio.c

2015-12-09 Thread Sudip Mukherjee
On Wed, Dec 09, 2015 at 03:46:02PM -0800, Benjamin Young wrote:
> From f18a3e5f155f5258d2d19ac6b56bfaafa2ad470b Mon Sep 17 00:00:00 2001
> From: Benjamin Young 
> Date: Wed, 9 Dec 2015 13:45:00 -0800
> Subject: [PATCH] Fixed coding style problems based on checkpatch.pl for
>  goldfish_audio.c

This should not be here.
You have not given in commit message and you are doing multiple changes
in this patch. Please split them into separate patch, each patch doing
only a single type of change.

regards
sudip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v9 7/7] PCI: hv: New paravirtual PCI front-end for Hyper-V VMs

2015-12-09 Thread kbuild test robot
Hi Jake,

[auto build test WARNING on pci/next]
[also build test WARNING on v4.4-rc4 next-20151209]

url:
https://github.com/0day-ci/linux/commits/jakeo-microsoft-com/PCI-hv-New-paravirtual-PCI-front-end-for-Hyper-V-VMs/20151210-070027
base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: x86_64-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   include/linux/compiler.h:228:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
   drivers/pci/host/hv_pcifront.c: In function 'hv_pci_allocate_bridge_windows':
>> drivers/pci/host/hv_pcifront.c:1776:18: warning: unused variable 'length' 
>> [-Wunused-variable]
 resource_size_t length;
 ^

vim +/length +1776 drivers/pci/host/hv_pcifront.c

  1760  hbus->high_mmio_res->flags |= IORESOURCE_BUSY;
  1761  release_mem_region(hbus->high_mmio_res->start,
  1762 resource_size(hbus->high_mmio_res));
  1763  }
  1764  }
  1765  
  1766  /**
  1767   * hv_pci_allocate_bridge_windows() - Allocate memory regions
  1768   * for the bus
  1769   * @hbus:   Root PCI bus, as understood by this driver
  1770   *
  1771   * Return: 0 on success, -errno on failure
  1772   */
  1773  static int hv_pci_allocate_bridge_windows(struct hv_pcibus_device *hbus)
  1774  {
  1775  resource_size_t align;
> 1776  resource_size_t length;
  1777  int ret;
  1778  
  1779  if (hbus->low_mmio_space) {
  1780  align = 1ULL << (63 - 
__builtin_clzll(hbus->low_mmio_space));
  1781  ret = vmbus_allocate_mmio(>low_mmio_res, 
hbus->hdev, 0,
  1782  0xULL,
  1783  
(resource_size_t)hbus->low_mmio_space,
  1784  align, false);

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


.config.gz
Description: Binary data
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] tools: hv: vss: fix the write()'s argument: error -> vss_msg

2015-12-09 Thread Dexuan Cui
I found this by chance. I don't have a specific bug caused by this.

Cc: Vitaly Kuznetsov 
Cc: "K. Y. Srinivasan" 
Signed-off-by: Dexuan Cui 
Cc: sta...@vger.kernel.org
---
 tools/hv/hv_vss_daemon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/hv/hv_vss_daemon.c b/tools/hv/hv_vss_daemon.c
index 96234b6..5d51d6f 100644
--- a/tools/hv/hv_vss_daemon.c
+++ b/tools/hv/hv_vss_daemon.c
@@ -254,7 +254,7 @@ int main(int argc, char *argv[])
syslog(LOG_ERR, "Illegal op:%d\n", op);
}
vss_msg->error = error;
-   len = write(vss_fd, , sizeof(struct hv_vss_msg));
+   len = write(vss_fd, vss_msg, sizeof(struct hv_vss_msg));
if (len != sizeof(struct hv_vss_msg)) {
syslog(LOG_ERR, "write failed; error: %d %s", errno,
   strerror(errno));
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Call to confirm !!

2015-12-09 Thread UNITED NATIONS PAYMENT NOTIFICATION
WESTERN UNION MONEY TRANSFER 
ITALY PAY-OUT CENTER 

Dear Western Union Beneficiary,

UNITED NATIONS PAYMENT NOTIFICATION. 

We wish to inform you that the United Nations (UN) has authorized us to remit 
to you a total amount of $500,000.00, (Five Hundred Thousand United States 
Dollars).  

Your Cash prize was paid out to us by the United Nations, and they have 
successfully succeeded in depositing your whole funds with us Here at Western 
Union Italy. 

They have now ordered us to take full responsibility in the transfer process of 
your funds and thus commence the immediate remittance of your funds to you. 

Be duly informed that because of our Western Union transfer policy, your funds 
will be paid to you via our Western Union Daily Transfer limit of $4,600.00 
USD. This means that you will Continuously receive a daily amount of $4,600.00 
USD, and this amount Can be collected from any of our numerous Western Union 
outlets in your current location. 

To begin the claim process of your daily payment as stated above, kindly 
furnish us with the following; 

Full Name: 
Address: 
Phone Number: 

Upon the receipt of the above mentioned details, your first transaction will be 
activated and we shall then Proceed to provide you with the Money Transfer 
Control Number (MTCN) for the First installment and we will continue to email 
you others after 12 hours of Receiving each payment. 

For more information on your payment status; 

Contact Person
Elena Paciotti For
Dario Pellizzari

OR call our 24 hours Helpline @ +39 389 230 3166, for any inquiries on the 
above message. 

Yours truly, 

Elena Paciotti

For: Western Union Italy. 
WESTERN UNION... Over 380,000 Outlets Worldwide
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v9 7/7] PCI: hv: New paravirtual PCI front-end for Hyper-V VMs

2015-12-09 Thread kbuild test robot
Hi Jake,

[auto build test ERROR on pci/next]
[also build test ERROR on v4.4-rc4 next-20151209]

url:
https://github.com/0day-ci/linux/commits/jakeo-microsoft-com/PCI-hv-New-paravirtual-PCI-front-end-for-Hyper-V-VMs/20151210-070027
base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: x86_64-randconfig-x006-12100835 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/pci/host/hv_pcifront.c: In function 'hv_compose_msi_msg':
>> drivers/pci/host/hv_pcifront.c:830:4: error: 'apic' undeclared (first use in 
>> this function)
  (apic->irq_delivery_mode == dest_LowestPrio) ? 1 : 0;
   ^
   drivers/pci/host/hv_pcifront.c:830:4: note: each undeclared identifier is 
reported only once for each function it appears in
   drivers/pci/host/hv_pcifront.c: In function 'hv_pci_allocate_bridge_windows':
   drivers/pci/host/hv_pcifront.c:1776:18: warning: unused variable 'length' 
[-Wunused-variable]
 resource_size_t length;
 ^

vim +/apic +830 drivers/pci/host/hv_pcifront.c

   824  int_pkt = (struct pci_create_interrupt *)
   825  int_pkt->message_type.message_type = 
PCI_CREATE_INTERRUPT_MESSAGE;
   826  int_pkt->wslot.slot = hpdev->desc.win_slot.slot;
   827  int_pkt->int_desc.vector = cfg->vector;
   828  int_pkt->int_desc.vector_count = 1;
   829  int_pkt->int_desc.delivery_mode =
 > 830  (apic->irq_delivery_mode == dest_LowestPrio) ? 1 : 0;
   831  
   832  /*
   833   * This bit doesn't have to work on machines with more than 64

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


.config.gz
Description: Binary data
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v8 1/7] drivers:hv: Export a function that maps Linux CPU num onto Hyper-V proc num

2015-12-09 Thread jakeo
From: Jake Oshins 

This patch exposes the mapping between Linux CPU number and Hyper-V
virtual processor number. This is necessary because the hypervisor needs
to know which virtual processor to target when making a mapping in the
Interrupt Redirection Table in the I/O MMU.

Signed-off-by: Jake Oshins 
---
 drivers/hv/vmbus_drv.c | 17 +
 include/linux/hyperv.h |  2 ++
 2 files changed, 19 insertions(+)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index f19b6f7..c89d0e5 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1191,6 +1191,23 @@ int vmbus_allocate_mmio(struct resource **new, struct 
hv_device *device_obj,
 }
 EXPORT_SYMBOL_GPL(vmbus_allocate_mmio);
 
+/**
+ * vmbus_cpu_number_to_vp_number() - Map CPU to VP.
+ * @cpu_number: CPU number in Linux terms
+ *
+ * This function returns the mapping between the Linux processor
+ * number and the hypervisor's virtual processor number, useful
+ * in making hypercalls and such that talk about specific
+ * processors.
+ *
+ * Return: Virtual processor number in Hyper-V terms
+ */
+int vmbus_cpu_number_to_vp_number(int cpu_number)
+{
+   return hv_context.vp_index[cpu_number];
+}
+EXPORT_SYMBOL_GPL(vmbus_cpu_number_to_vp_number);
+
 static int vmbus_acpi_add(struct acpi_device *device)
 {
acpi_status result;
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 8fdc17b..fddb3e0 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -983,6 +983,8 @@ int vmbus_allocate_mmio(struct resource **new, struct 
hv_device *device_obj,
resource_size_t size, resource_size_t align,
bool fb_overlap_ok);
 
+int vmbus_cpu_number_to_vp_number(int cpu_number);
+
 /**
  * VMBUS_DEVICE - macro used to describe a specific hyperv vmbus device
  *
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v8 5/7] PCI: irqdomain: Look up IRQ domain by fwnode_handle

2015-12-09 Thread jakeo
From: Jake Oshins 

This patch adds a second way of finding an IRQ domain associated with
a root PCI bus.  After looking to see if one can be found through
the OF tree, it attempts to look up the IRQ domain through an
fwnode_handle stored in the pci_sysdata struct.

Signed-off-by: Jake Oshins 
---
 drivers/pci/probe.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 750f907..c6369dd 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -674,6 +674,20 @@ static struct irq_domain 
*pci_host_bridge_msi_domain(struct pci_bus *bus)
 */
d = pci_host_bridge_of_msi_domain(bus);
 
+#ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
+   /*
+* If no IRQ domain was found via the OF tree, try looking it up
+* directly through the fwnode_handle.
+*/
+   if (!d) {
+   struct fwnode_handle *fwnode = pci_root_bus_fwnode(bus);
+
+   if (fwnode)
+   d = irq_find_matching_fwnode(fwnode,
+DOMAIN_BUS_PCI_MSI);
+   }
+#endif
+
return d;
 }
 
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v8 4/7] PCI: Add fwnode_handle to pci_sysdata

2015-12-09 Thread jakeo
From: Jake Oshins 

This patch adds an fwnode_handle to struct pci_sysdata, which is
used by the next patch in the series when trying to locate an
IRQ domain associated with a root PCI bus.

Signed-off-by: Jake Oshins 
---
 arch/x86/include/asm/pci.h | 15 +++
 drivers/pci/probe.c|  1 +
 include/linux/pci.h|  4 
 3 files changed, 20 insertions(+)

diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index 4625943..6fc3c7c 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -20,6 +20,9 @@ struct pci_sysdata {
 #ifdef CONFIG_X86_64
void*iommu; /* IOMMU private data */
 #endif
+#ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
+   void*fwnode;/* IRQ domain for MSI assignment */
+#endif
 };
 
 extern int pci_routeirq;
@@ -32,6 +35,7 @@ extern int noioapicreroute;
 static inline int pci_domain_nr(struct pci_bus *bus)
 {
struct pci_sysdata *sd = bus->sysdata;
+
return sd->domain;
 }
 
@@ -41,6 +45,17 @@ static inline int pci_proc_domain(struct pci_bus *bus)
 }
 #endif
 
+#ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
+static inline void *_pci_root_bus_fwnode(struct pci_bus *bus)
+{
+   struct pci_sysdata *sd = bus->sysdata;
+
+   return sd->fwnode;
+}
+
+#define pci_root_bus_fwnode_pci_root_bus_fwnode
+#endif
+
 /* Can be used to override the logic in pci_scan_bus for skipping
already-configured bus numbers - to be used for buggy BIOSes
or architectures with incomplete PCI setup by the loader */
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index edb1984..750f907 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "pci.h"
 
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 6ae25aa..b414422 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1517,6 +1517,10 @@ static inline int pci_get_new_domain_nr(void) { return 
-ENOSYS; }
 
 #include 
 
+#ifndef pci_root_bus_fwnode
+#define pci_root_bus_fwnode(bus)   ((void)(bus), NULL)
+#endif
+
 /* these helpers provide future and backwards compatibility
  * for accessing popular PCI BAR info */
 #define pci_resource_start(dev, bar)   ((dev)->resource[(bar)].start)
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v8 7/7] PCI: hv: New paravirtual PCI front-end for Hyper-V VMs

2015-12-09 Thread jakeo
From: Jake Oshins 

This patch introduces a new driver which exposes a root PCI bus whenever a
PCI Express device is passed through to a guest VM under Hyper-V. The
device can be single- or multi-function. The interrupts for the devices
are managed by an IRQ domain, implemented within the driver.

Signed-off-by: Jake Oshins 
---
 MAINTAINERS|1 +
 drivers/pci/Kconfig|7 +
 drivers/pci/host/Makefile  |1 +
 drivers/pci/host/hv_pcifront.c | 2249 
 4 files changed, 2258 insertions(+)
 create mode 100644 drivers/pci/host/hv_pcifront.c

diff --git a/MAINTAINERS b/MAINTAINERS
index e6ec986..40747e8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5115,6 +5115,7 @@ F:arch/x86/kernel/cpu/mshyperv.c
 F: drivers/hid/hid-hyperv.c
 F: drivers/hv/
 F: drivers/input/serio/hyperv-keyboard.c
+F: drivers/pci/host/hv_pcifront.c
 F: drivers/net/hyperv/
 F: drivers/scsi/storvsc_drv.c
 F: drivers/video/fbdev/hyperv_fb.c
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 73de4ef..9b82d93 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -118,4 +118,11 @@ config PCI_LABEL
def_bool y if (DMI || ACPI)
select NLS
 
+config HYPERV_VPCI
+tristate "Hyper-V PCI Frontend"
+depends on PCI && X86 && HYPERV && PCI_MSI && PCI_MSI_IRQ_DOMAIN
+help
+  The PCI device frontend driver allows the kernel to import arbitrary
+  PCI devices from a PCI backend to support PCI driver domains.
+
 source "drivers/pci/host/Kconfig"
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 9d4d3c6..d9abd2a 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_PCIE_DW) += pcie-designware.o
 obj-$(CONFIG_PCI_DRA7XX) += pci-dra7xx.o
 obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
 obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
+obj-$(CONFIG_HYPERV_VPCI) += hv_pcifront.o
 obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
 obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o
 obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o
diff --git a/drivers/pci/host/hv_pcifront.c b/drivers/pci/host/hv_pcifront.c
new file mode 100644
index 000..56da07e
--- /dev/null
+++ b/drivers/pci/host/hv_pcifront.c
@@ -0,0 +1,2249 @@
+/*
+ * Copyright (c) Microsoft Corporation.
+ *
+ * Author:
+ *   Jake Oshins 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
+ * NON INFRINGEMENT.  See the GNU General Public License for more
+ * details.
+ *
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Protocol versions. The low word is the minor version, the high word the 
major
+ * version.
+ */
+
+#define PCI_MAKE_VERSION(major, minor) ((__u32)(((major) << 16) | (major)))
+#define PCI_MAJOR_VERSION(version) ((__u32)(version) >> 16)
+#define PCI_MINOR_VERSION(version) ((__u32)(version) & 0xff)
+
+enum {
+   PCI_PROTOCOL_VERSION_1_1 = PCI_MAKE_VERSION(1, 1),
+   PCI_PROTOCOL_VERSION_CURRENT = PCI_PROTOCOL_VERSION_1_1
+};
+
+#define PCI_CONFIG_MMIO_LENGTH 0x2000
+#define MAX_SUPPORTED_MSI_MESSAGES 0x400
+
+/*
+ * Message Types
+ */
+
+enum pci_message_type {
+   /*
+* Version 1.1
+*/
+   PCI_MESSAGE_BASE= 0x4249,
+   PCI_BUS_RELATIONS   = PCI_MESSAGE_BASE + 0,
+   PCI_QUERY_BUS_RELATIONS = PCI_MESSAGE_BASE + 1,
+   PCI_POWER_STATE_CHANGE  = PCI_MESSAGE_BASE + 4,
+   PCI_QUERY_RESOURCE_REQUIREMENTS = PCI_MESSAGE_BASE + 5,
+   PCI_QUERY_RESOURCE_RESOURCES= PCI_MESSAGE_BASE + 6,
+   PCI_BUS_D0ENTRY = PCI_MESSAGE_BASE + 7,
+   PCI_BUS_D0EXIT  = PCI_MESSAGE_BASE + 8,
+   PCI_READ_BLOCK  = PCI_MESSAGE_BASE + 9,
+   PCI_WRITE_BLOCK = PCI_MESSAGE_BASE + 0xA,
+   PCI_EJECT   = PCI_MESSAGE_BASE + 0xB,
+   PCI_QUERY_STOP  = PCI_MESSAGE_BASE + 0xC,
+   PCI_REENABLE= PCI_MESSAGE_BASE + 0xD,
+   PCI_QUERY_STOP_FAILED   = PCI_MESSAGE_BASE + 0xE,
+   PCI_EJECTION_COMPLETE   = PCI_MESSAGE_BASE + 0xF,
+   PCI_RESOURCES_ASSIGNED  = PCI_MESSAGE_BASE + 0x10,
+   PCI_RESOURCES_RELEASED  = PCI_MESSAGE_BASE + 0x11,
+   PCI_INVALIDATE_BLOCK= PCI_MESSAGE_BASE + 0x12,
+   PCI_QUERY_PROTOCOL_VERSION  = PCI_MESSAGE_BASE + 0x13,
+   PCI_CREATE_INTERRUPT_MESSAGE= 

[PATCH v8 0/7] PCI: hv: New paravirtual PCI front-end for Hyper-V VMs

2015-12-09 Thread jakeo
From: Jake Oshins 

This version of the patch series incorporates feedback from Mark Zyngier,
making this build on arm/arm64.

First, export functions that allow correlating Hyper-V virtual processors
and Linux cpus, along with the means for invoking a hypercall that targets
interrupts at chosen vectors on specific cpus.

Second, mark various parts of IRQ domain related code as exported, so that
this PCI front-end can implement an IRQ domain as part of a module.  (The
alternative would be to pull all tyhis into the kernel, which would pull
in a lot of other Hyper-V related code, as this IRQ domain depends on
vmbus.ko.)

Third, modify PCI so that new root PCI buses can be marked with an associated
fwnode_handle, and so that root PCI buses can look up their associated IRQ
domain by that handle.

Fourth, introduce a new driver, hv_pcifront, which exposes root PCI buses in
a Hyper-V VM.  These root PCI buses expose real PCIe device, or PCI Virtual
Functions.

Jake Oshins (7):
  drivers:hv: Export a function that maps Linux CPU num onto Hyper-V
proc num
  drivers:hv: Export hv_do_hypercall()
  PCI: Make it possible to implement a PCI MSI IRQ Domain in a module.
  PCI: Add fwnode_handle to pci_sysdata
  PCI: irqdomain: Look up IRQ domain by fwnode_handle
  drivers:hv: Define the channel type of Hyper-V PCI Express
pass-through
  PCI: hv: New paravirtual PCI front-end for Hyper-V VMs

 MAINTAINERS|1 +
 arch/x86/include/asm/msi.h |6 +
 arch/x86/include/asm/pci.h |   15 +
 arch/x86/kernel/apic/msi.c |8 +-
 arch/x86/kernel/apic/vector.c  |2 +
 drivers/hv/hv.c|   20 +-
 drivers/hv/hyperv_vmbus.h  |2 +-
 drivers/hv/vmbus_drv.c |   17 +
 drivers/pci/Kconfig|7 +
 drivers/pci/host/Makefile  |1 +
 drivers/pci/host/hv_pcifront.c | 2249 
 drivers/pci/msi.c  |4 +
 drivers/pci/probe.c|   15 +
 include/linux/hyperv.h |   14 +
 include/linux/pci.h|4 +
 kernel/irq/chip.c  |1 +
 kernel/irq/irqdomain.c |4 +
 17 files changed, 2356 insertions(+), 14 deletions(-)
 create mode 100644 drivers/pci/host/hv_pcifront.c

-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v8 2/7] drivers:hv: Export hv_do_hypercall()

2015-12-09 Thread jakeo
From: Jake Oshins 

This patch exposes the function that hv_vmbus.ko uses to make hypercalls.
This is necessary for retargeting an interrupt when it is given a new
affinity and vector.

Signed-off-by: Jake Oshins 
---
 drivers/hv/hv.c   | 20 ++--
 drivers/hv/hyperv_vmbus.h |  2 +-
 include/linux/hyperv.h|  1 +
 3 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 6341be8..7a06933 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -89,9 +89,9 @@ static int query_hypervisor_info(void)
 }
 
 /*
- * do_hypercall- Invoke the specified hypercall
+ * hv_do_hypercall- Invoke the specified hypercall
  */
-static u64 do_hypercall(u64 control, void *input, void *output)
+u64 hv_do_hypercall(u64 control, void *input, void *output)
 {
u64 input_address = (input) ? virt_to_phys(input) : 0;
u64 output_address = (output) ? virt_to_phys(output) : 0;
@@ -132,6 +132,7 @@ static u64 do_hypercall(u64 control, void *input, void 
*output)
return hv_status_lo | ((u64)hv_status_hi << 32);
 #endif /* !x86_64 */
 }
+EXPORT_SYMBOL_GPL(hv_do_hypercall);
 
 #ifdef CONFIG_X86_64
 static cycle_t read_hv_clock_tsc(struct clocksource *arg)
@@ -315,7 +316,7 @@ int hv_post_message(union hv_connection_id connection_id,
 {
 
struct hv_input_post_message *aligned_msg;
-   u16 status;
+   u64 status;
 
if (payload_size > HV_MESSAGE_PAYLOAD_BYTE_COUNT)
return -EMSGSIZE;
@@ -329,11 +330,10 @@ int hv_post_message(union hv_connection_id connection_id,
aligned_msg->payload_size = payload_size;
memcpy((void *)aligned_msg->payload, payload, payload_size);
 
-   status = do_hypercall(HVCALL_POST_MESSAGE, aligned_msg, NULL)
-   & 0x;
+   status = hv_do_hypercall(HVCALL_POST_MESSAGE, aligned_msg, NULL);
 
put_cpu();
-   return status;
+   return status & 0x;
 }
 
 
@@ -343,13 +343,13 @@ int hv_post_message(union hv_connection_id connection_id,
  *
  * This involves a hypercall.
  */
-u16 hv_signal_event(void *con_id)
+int hv_signal_event(void *con_id)
 {
-   u16 status;
+   u64 status;
 
-   status = (do_hypercall(HVCALL_SIGNAL_EVENT, con_id, NULL) & 0x);
+   status = hv_do_hypercall(HVCALL_SIGNAL_EVENT, con_id, NULL);
 
-   return status;
+   return status & 0x;
 }
 
 static int hv_ce_set_next_event(unsigned long delta,
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 3782636..cc2fb53 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -582,7 +582,7 @@ extern int hv_post_message(union hv_connection_id 
connection_id,
 enum hv_message_type message_type,
 void *payload, size_t payload_size);
 
-extern u16 hv_signal_event(void *con_id);
+extern int hv_signal_event(void *con_id);
 
 extern int hv_synic_alloc(void);
 
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index fddb3e0..24d0b65 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -984,6 +984,7 @@ int vmbus_allocate_mmio(struct resource **new, struct 
hv_device *device_obj,
bool fb_overlap_ok);
 
 int vmbus_cpu_number_to_vp_number(int cpu_number);
+u64 hv_do_hypercall(u64 control, void *input, void *output);
 
 /**
  * VMBUS_DEVICE - macro used to describe a specific hyperv vmbus device
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v8 6/7] drivers:hv: Define the channel type of Hyper-V PCI Express pass-through

2015-12-09 Thread jakeo
From: Jake Oshins 

This defines the channel type for PCI front-ends in Hyper-V VMs.

Signed-off-by: Jake Oshins 
---
 include/linux/hyperv.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 24d0b65..c9a9eed 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1141,6 +1141,17 @@ u64 hv_do_hypercall(u64 control, void *input, void 
*output);
}
 
 /*
+ * PCI Express Pass Through
+ * {44C4F61D--4400-9D52-802E27EDE19F}
+ */
+
+#define HV_PCIE_GUID \
+   .guid = { \
+   0x1D, 0xF6, 0xC4, 0x44, 0x44, 0x44, 0x00, 0x44, \
+   0x9D, 0x52, 0x80, 0x2E, 0x27, 0xED, 0xE1, 0x9F \
+   }
+
+/*
  * Common header for Hyper-V ICs
  */
 
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v7 4/7] PCI: Add fwnode_handle to pci_sysdata

2015-12-09 Thread Marc Zyngier
On 09/12/15 16:54, Jake Oshins wrote:
>> -Original Message-
>> From: Marc Zyngier [mailto:marc.zyng...@arm.com]
>> Sent: Wednesday, December 9, 2015 8:51 AM
>> To: Jake Oshins ; gre...@linuxfoundation.org; KY
>> Srinivasan ; linux-ker...@vger.kernel.org;
>> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
>> vkuzn...@redhat.com; t...@linutronix.de; Haiyang Zhang
>> ; bhelg...@google.com; linux-
>> p...@vger.kernel.org
>> Subject: Re: [PATCH v7 4/7] PCI: Add fwnode_handle to pci_sysdata
>>
>> On 05/12/15 00:36, ja...@microsoft.com wrote:
>>> From: Jake Oshins 
>>>
>>> This patch adds an fwnode_handle to struct pci_sysdata, which is
>>> used by the next patch in the series when trying to locate an
>>> IRQ domain associated with a root PCI bus.
>>>
>>> Signed-off-by: Jake Oshins 
>>> ---
>>>  arch/x86/include/asm/pci.h | 15 +++
>>>  include/asm-generic/pci.h  |  4 
>>>  2 files changed, 19 insertions(+)
>>>
>>
>> [...]
>>
>>> diff --git a/include/asm-generic/pci.h b/include/asm-generic/pci.h
>>> index f24bc51..4092886 100644
>>> --- a/include/asm-generic/pci.h
>>> +++ b/include/asm-generic/pci.h
>>> @@ -21,4 +21,8 @@ static inline int pci_get_legacy_ide_irq(struct pci_dev
>> *dev, int channel)
>>>  #define PCI_DMA_BUS_IS_PHYS(1)
>>>  #endif
>>>
>>> +#ifndef pci_root_bus_fwnode
>>> +#define pci_root_bus_fwnode(bus)   ((void)(bus), NULL)
>>> +#endif
>>> +
>>>  #endif /* _ASM_GENERIC_PCI_H */
>>>
>>
>> This breaks at least arm64 (as you can see from the reply to patch #5,
>> because it does have its own asm/pci.h. Instead, how about moving this
>> to linux/pci.h, just after the include of asm/pci.h? I just gave it a
>> go, and it seems to work nicely (the first hunk fixes the rest of the
>> arm64 compile issue):
> 
> Thank you.  I was just working through how to do that.  I lost a
> couple of days trying to figure out how to cross-compile for arm64 to
> check that any fix that I made actually worked.  (In the process,
> I've completely messed up my development machine.  Any pointers to
> the right strategy would be appreciated.)

My own strategy is pretty simple. It involves:
- downloading a binary toolchain ([1] for example)
- untar this somewhere, putting the
gcc-linaro-5.2-2015.11-x86_64_aarch64-linux-gnu/bin directory in your PATH
- and then the usual "make ARCH=arm64 defconfig && make ARCH=arm64
CROSS_COMPILE=aarch64-linux-gnu- all"

That's of course assuming you're using a Linux x86-64 box for
cross-compiling. I also cross-compile from 32bit ARM, but I doubt you'd
be interested... ;-)

Cheers,

M.

[1]
https://releases.linaro.org/components/toolchain/binaries/5.2-2015.11/aarch64-linux-gnu/gcc-linaro-5.2-2015.11-x86_64_aarch64-linux-gnu.tar.xz
-- 
Jazz is not dead. It just smells funny...
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel