[PATCH 5/5] PCI: hv: hv_pci_generic_compl(): handle the error case

2016-08-22 Thread Dexuan Cui

'completetion_status' is used in some places, e.g.,
hv_pci_protocol_negotiation(), so we should make sure it's initialized in
error case too, though the error is unlikely here.

I didn't get a real issue.

Cc: Jake Oshins 
Cc: K. Y. Srinivasan 
Cc: Haiyang Zhang 
Cc: Vitaly Kuznetsov 
Signed-off-by: Dexuan Cui 
---
 drivers/pci/host/pci-hyperv.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index f337239..a93bd5d 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -456,6 +456,9 @@ hv_pci_generic_compl(void *context, struct pci_response 
*resp,
 
if (resp_packet_size >= offsetofend(struct pci_response, status))
comp_pkt->completion_status = resp->status;
+   else
+   comp_pkt->completion_status = -1;
+
complete(_pkt->host_event);
 }
 
-- 
2.7.4

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


[PATCH 4/5] PCI: hv: hv_compose_msi_msg: handle the 'ret' value

2016-08-22 Thread Dexuan Cui

I happened to find this when reading the code.
I didn't get a real issue however.

Cc: Jake Oshins 
Cc: K. Y. Srinivasan 
Cc: Haiyang Zhang 
Cc: Vitaly Kuznetsov 
Signed-off-by: Dexuan Cui 
---
 drivers/pci/host/pci-hyperv.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index aef2e1e..f337239 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -893,8 +893,10 @@ static void hv_compose_msi_msg(struct irq_data *data, 
struct msi_msg *msg)
   sizeof(*int_pkt), (unsigned long),
   VM_PKT_DATA_INBAND,
   VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
-   if (!ret)
-   wait_for_completion(_pkt.host_event);
+   if (ret)
+   goto free_int_desc;
+
+   wait_for_completion(_pkt.host_event);
 
if (comp.comp_pkt.completion_status < 0) {
dev_err(>hdev->device,
-- 
2.7.4

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


[PATCH 3/5] PCI: hv: remove the unused 'wrk' in struct hv_pcibus_device

2016-08-22 Thread Dexuan Cui

The member is not used.

Cc: Jake Oshins 
Cc: K. Y. Srinivasan 
Cc: Haiyang Zhang 
Cc: Vitaly Kuznetsov 
Signed-off-by: Dexuan Cui 
---
 drivers/pci/host/pci-hyperv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index cdbadea5..aef2e1e 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -374,7 +374,6 @@ struct hv_pcibus_device {
 
struct list_head children;
struct list_head dr_list;
-   struct work_struct wrk;
 
struct msi_domain_info msi_info;
struct msi_controller msi_chip;
-- 
2.7.4

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


[PATCH 2/5] PCI: hv: use pci_function_description[0] in struct definitions

2016-08-22 Thread Dexuan Cui

The 2 structs can use a zero-length array here, because dynamic memory of
the correct size is allocated in hv_pci_devices_present() and we don't
need this extra element.

No functional change.

Cc: Jake Oshins 
Cc: K. Y. Srinivasan 
Cc: Haiyang Zhang 
Cc: Vitaly Kuznetsov 
Signed-off-by: Dexuan Cui 
---
 drivers/pci/host/pci-hyperv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index 78758e9..cdbadea5 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -259,7 +259,7 @@ struct pci_bus_d0_entry {
 struct pci_bus_relations {
struct pci_incoming_message incoming;
u32 device_count;
-   struct pci_function_description func[1];
+   struct pci_function_description func[0];
 } __packed;
 
 struct pci_q_res_req_response {
@@ -394,7 +394,7 @@ struct hv_dr_work {
 struct hv_dr_state {
struct list_head list_entry;
u32 device_count;
-   struct pci_function_description func[1];
+   struct pci_function_description func[0];
 };
 
 enum hv_pcichild_state {
-- 
2.7.4

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


[PATCH 1/5] PCI: hv: use zero-length array in struct pci_packet

2016-08-22 Thread Dexuan Cui

And, rename struct pci_message's field "message_type" to "type.

This makes the code more readable.

No functionality change.

Cc: Jake Oshins 
Cc: K. Y. Srinivasan 
Cc: Haiyang Zhang 
Cc: Vitaly Kuznetsov 
Signed-off-by: Dexuan Cui 
---
 drivers/pci/host/pci-hyperv.c | 42 --
 1 file changed, 20 insertions(+), 22 deletions(-)

diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index 7e9b2de..78758e9 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -200,11 +200,11 @@ struct tran_int_desc {
  */
 
 struct pci_message {
-   u32 message_type;
+   u32 type;
 } __packed;
 
 struct pci_child_message {
-   u32 message_type;
+   struct pci_message message_type;
union win_slot_encoding wslot;
 } __packed;
 
@@ -222,7 +222,8 @@ struct pci_packet {
void (*completion_func)(void *context, struct pci_response *resp,
int resp_packet_size);
void *compl_ctxt;
-   struct pci_message message;
+
+   struct pci_message message[0];
 };
 
 /*
@@ -314,7 +315,7 @@ struct pci_dev_incoming {
 } __packed;
 
 struct pci_eject_response {
-   u32 message_type;
+   struct pci_message message_type;
union win_slot_encoding wslot;
u32 status;
 } __packed;
@@ -694,13 +695,12 @@ static void hv_int_desc_free(struct hv_pci_dev *hpdev,
struct pci_delete_interrupt *int_pkt;
struct {
struct pci_packet pkt;
-   u8 buffer[sizeof(struct pci_delete_interrupt) -
- sizeof(struct pci_message)];
+   u8 buffer[sizeof(struct pci_delete_interrupt)];
} ctxt;
 
memset(, 0, sizeof(ctxt));
int_pkt = (struct pci_delete_interrupt *)
-   int_pkt->message_type.message_type =
+   int_pkt->message_type.type =
PCI_DELETE_INTERRUPT_MESSAGE;
int_pkt->wslot.slot = hpdev->desc.win_slot.slot;
int_pkt->int_desc = *int_desc;
@@ -845,8 +845,7 @@ static void hv_compose_msi_msg(struct irq_data *data, 
struct msi_msg *msg)
struct cpumask *affinity;
struct {
struct pci_packet pkt;
-   u8 buffer[sizeof(struct pci_create_interrupt) -
- sizeof(struct pci_message)];
+   u8 buffer[sizeof(struct pci_create_interrupt)];
} ctxt;
int cpu;
int ret;
@@ -874,7 +873,7 @@ static void hv_compose_msi_msg(struct irq_data *data, 
struct msi_msg *msg)
ctxt.pkt.completion_func = hv_pci_compose_compl;
ctxt.pkt.compl_ctxt = 
int_pkt = (struct pci_create_interrupt *)
-   int_pkt->message_type.message_type = PCI_CREATE_INTERRUPT_MESSAGE;
+   int_pkt->message_type.type = PCI_CREATE_INTERRUPT_MESSAGE;
int_pkt->wslot.slot = hpdev->desc.win_slot.slot;
int_pkt->int_desc.vector = cfg->vector;
int_pkt->int_desc.vector_count = 1;
@@ -1287,7 +1286,7 @@ static struct hv_pci_dev *new_pcichild_device(struct 
hv_pcibus_device *hbus,
pkt.init_packet.compl_ctxt = _pkt;
pkt.init_packet.completion_func = q_resource_requirements;
res_req = (struct pci_child_message *)_packet.message;
-   res_req->message_type = PCI_QUERY_RESOURCE_REQUIREMENTS;
+   res_req->message_type.type = PCI_QUERY_RESOURCE_REQUIREMENTS;
res_req->wslot.slot = desc->win_slot.slot;
 
ret = vmbus_sendpacket(hbus->hdev->channel, res_req,
@@ -1556,8 +1555,7 @@ static void hv_eject_device_work(struct work_struct *work)
int wslot;
struct {
struct pci_packet pkt;
-   u8 buffer[sizeof(struct pci_eject_response) -
- sizeof(struct pci_message)];
+   u8 buffer[sizeof(struct pci_eject_response)];
} ctxt;
 
hpdev = container_of(work, struct hv_pci_dev, wrk);
@@ -1583,7 +1581,7 @@ static void hv_eject_device_work(struct work_struct *work)
 
memset(, 0, sizeof(ctxt));
ejct_pkt = (struct pci_eject_response *)
-   ejct_pkt->message_type = PCI_EJECTION_COMPLETE;
+   ejct_pkt->message_type.type = PCI_EJECTION_COMPLETE;
ejct_pkt->wslot.slot = hpdev->desc.win_slot.slot;
vmbus_sendpacket(hpdev->hbus->hdev->channel, ejct_pkt,
 sizeof(*ejct_pkt), (unsigned long),
@@ -1685,7 +1683,7 @@ static void hv_pci_onchannelcallback(void *context)
case VM_PKT_DATA_INBAND:
 
new_message = (struct pci_incoming_message *)buffer;
-   switch (new_message->message_type.message_type) {
+   switch (new_message->message_type.type) {
case PCI_BUS_RELATIONS:
 
bus_rel = (struct pci_bus_relations *)buffer;
@@ -1716,7 +1714,7 @@ static void 

[PATCH 0/5] PCI: hv: some minor bug fixes and cleanups

2016-08-22 Thread Dexuan Cui

1. use zero-length array to make the code more readable.
2. remove an unused struct member.
3. small error handling improvement to some error cases.

Dexuan Cui (5):
  PCI: hv: use zero-length message in struct pci_packet
  PCI: hv: use pci_function_description[0] in struct definitions
  PCI: hv: remove the unused 'wrk' in struct hv_pcibus_device
  PCI: hv: hv_compose_msi_msg: handle the 'ret' value
  PCI: hv: hv_pci_generic_compl(): handle the error case

 drivers/pci/host/pci-hyperv.c | 56 ++-
 1 file changed, 29 insertions(+), 27 deletions(-)

-- 
2.7.4

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


RE: [PATCH 2/2] hv_pci: make hv_irq functions static

2016-08-22 Thread Dexuan Cui
> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf
> Of sthem...@exchange.microsoft.com
> Sent: Tuesday, August 23, 2016 1:33
> To: KY Srinivasan ; Haiyang Zhang
> 
> Cc: de...@linuxdriverproject.org; Stephen Hemminger
> 
> Subject: [PATCH 2/2] hv_pci: make hv_irq functions static
> 
> From: Stephen Hemminger 
> 
> Fix sparse warning because these functions only used in one file.
> 
> Signed-off-by: Stephen Hemminger 
> ---
>  drivers/pci/host/pci-hyperv.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
> index 6955ffdb..1ebe2b0 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -755,7 +755,7 @@ static int hv_set_affinity(struct irq_data *data, const
> struct cpumask *dest,
> return parent->chip->irq_set_affinity(parent, dest, force);
>  }
> 
> -void hv_irq_mask(struct irq_data *data)
> +static void hv_irq_mask(struct irq_data *data)
>  {
> pci_msi_mask_irq(data);
>  }
> @@ -770,7 +770,7 @@ void hv_irq_mask(struct irq_data *data)
>   * is built out of this PCI bus's instance GUID and the function
>   * number of the device.
>   */
> -void hv_irq_unmask(struct irq_data *data)
> +static void hv_irq_unmask(struct irq_data *data)
>  {
> struct msi_desc *msi_desc = irq_data_get_msi_desc(data);
> struct irq_cfg *cfg = irqd_cfg(data);
> --

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


RE: [PATCH 0/2] hyperv: minor cleanups

2016-08-22 Thread Dexuan Cui
> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf
> Of sthem...@exchange.microsoft.com
> Sent: Tuesday, August 23, 2016 1:33
> To: KY Srinivasan ; Haiyang Zhang
> 
> Cc: de...@linuxdriverproject.org; Stephen Hemminger
> 
> Subject: [PATCH 0/2] hyperv: minor cleanups
> 
> 
> From: Stephen Hemminger 
> 
> Sparse warnings from global data/functions that should be static
> 
> Stephen Hemminger (2):
>   hyperv: make mmio resource local
>   hv_pci: make hv_irq functions static
> 
>  drivers/hv/vmbus_drv.c|4 ++--
>  drivers/pci/host/pci-hyperv.c |4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> --

I also have a few clean-up patches for the driver. Will post them.

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


RE: [PATCH 1/2] hyperv: make mmio resource local

2016-08-22 Thread Dexuan Cui
> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf
> Of sthem...@exchange.microsoft.com
> Sent: Tuesday, August 23, 2016 1:33
> To: KY Srinivasan ; Haiyang Zhang
> 
> Cc: de...@linuxdriverproject.org; Stephen Hemminger
> 
> Subject: [PATCH 1/2] hyperv: make mmio resource local
> 
> This sender failed our fraud detection checks and may not be who they appear
> to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing
> 
> From: Stephen Hemminger 
> 
> This fixes a sparse warning because hyperv_mmio resources
> are only used in this one file and should be static.
> 
> Signed-off-by: Stephen Hemminger 
> ---
>  drivers/hv/vmbus_drv.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index e82f7e1..954d16a 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -105,8 +105,8 @@ static struct notifier_block hyperv_panic_block = {
> 
>  static const char *fb_mmio_name = "fb_range";
>  static struct resource *fb_mmio;
> -struct resource *hyperv_mmio;
> -DEFINE_SEMAPHORE(hyperv_mmio_lock);
> +static struct resource *hyperv_mmio;
> +static DEFINE_SEMAPHORE(hyperv_mmio_lock);
> 
>  static int vmbus_exists(void)
>  {
> --

I also found this and was trying to fix this. :-)

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


[PATCH] staging: iio: accel: sca3000: remove extra space

2016-08-22 Thread Clifton Barnes
fix checkpatch.pl warning about 'Statements should start on a
tabstop'

Signed-off-by: Clifton Barnes 
---
 drivers/staging/iio/accel/sca3000_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/iio/accel/sca3000_core.c 
b/drivers/staging/iio/accel/sca3000_core.c
index b5625f5..61f3241 100644
--- a/drivers/staging/iio/accel/sca3000_core.c
+++ b/drivers/staging/iio/accel/sca3000_core.c
@@ -412,7 +412,7 @@ static const struct iio_event_spec sca3000_event = {
},  \
.event_spec = _event,   \
.num_event_specs = 1,   \
-}
+   }
 
 static const struct iio_chan_spec sca3000_channels[] = {
SCA3000_CHAN(0, IIO_MOD_X),
-- 
2.7.4

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


Re: [PATCH] staging: i4l: icn: fix memdup_user.cocci warnings

2016-08-22 Thread Greg Kroah-Hartman
On Tue, Aug 23, 2016 at 08:36:58AM +0800, kbuild test robot wrote:
> drivers/staging/i4l/icn/icn.c:813:11-18: WARNING opportunity for memdup_user
> 
>  Use memdup_user rather than duplicating its implementation
>  This is a little bit restricted to reduce false positives
> 
> Generated by: scripts/coccinelle/api/memdup_user.cocci
> 
> CC: Sudip Mukherjee 
> Signed-off-by: Fengguang Wu 
> ---
> 
>  0 files changed
> 
> rule starting on line 17: position variables or mixed modifs interfere with 
> comm_assoc isobool (
> (
> 
> (
> (unknown *to == NULL)
>   >>> IS_ERR(rule starting on line 17:to)
> 
> |
> !unknown *to
>   >>> IS_ERR(rule starting on line 17:to)
> 
> )
> |
> (unknown *NULL == unknown *to)
>   >>> IS_ERR(rule starting on line 17:to)
> 
> ) || ...)

There's no patch here, did something go wrong?

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


[staging:staging-testing 251/347] drivers/staging/i4l/icn/icn.c:813:11-18: WARNING opportunity for memdup_user

2016-08-22 Thread kbuild test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
staging-testing
head:   f5a9a15f8fd4168e415e94f5dce367f3cef08e03
commit: ee05e5f7113ea0b0db7eff7011a534c92fec2648 [251/347] staging: i4l: icn: 
donot assign in if statement


coccinelle warnings: (new ones prefixed by >>)

>> drivers/staging/i4l/icn/icn.c:813:11-18: WARNING opportunity for memdup_user

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] staging: i4l: icn: fix memdup_user.cocci warnings

2016-08-22 Thread kbuild test robot
drivers/staging/i4l/icn/icn.c:813:11-18: WARNING opportunity for memdup_user

 Use memdup_user rather than duplicating its implementation
 This is a little bit restricted to reduce false positives

Generated by: scripts/coccinelle/api/memdup_user.cocci

CC: Sudip Mukherjee 
Signed-off-by: Fengguang Wu 
---

 0 files changed

rule starting on line 17: position variables or mixed modifs interfere with 
comm_assoc isobool (
(

(
(unknown *to == NULL)
  >>> IS_ERR(rule starting on line 17:to)

|
!unknown *to
  >>> IS_ERR(rule starting on line 17:to)

)
|
(unknown *NULL == unknown *to)
  >>> IS_ERR(rule starting on line 17:to)

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


KЛИЕHTCKИЕ БАЗЫ MАЙЛ:kimmideze-5...@monmail.fr.nf CKАЙП: prodawez389 Для 6ыcmрoй мАccoвoй прoqАжu ВАшuх moвАрoв u уcлуr! Пoqрo6нocmu узнАйme ceйчАc!

2016-08-22 Thread de...@driverdev.osuosl.org
Сo6ерeм qля Ваc по инmeрнет базу qанныx пoтeнциальных клиентов gля Вaшeго 
Бизнecа! B базe бygym всe koнmaктные gaнные нeо6xодuмые gля мacсoвoй пpoдажи 
Bашuх товарoв и уcлуr. Пo Вaшему зanросу пpuшлем примeр и nодрo6нyю инфoрмацию. 
Если uнmeресно зaпpocuтe подрoбноcmи сeйчac МАЙЛ: kimmideze-5...@monmail.fr.nf 
СКAЙП: prodawez389 Благодaрим за 6ыстрый oтвеm

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


Re: [PATCH] staging: rts5208: rtsx.c: Fix checkpatch warnings.

2016-08-22 Thread Ming-Chia Chung
On Mon, Aug 22, 2016 at 10:51:27PM +0530, Sudip Mukherjee wrote:
> On Tue, Aug 23, 2016 at 12:54:17AM +0800, MingChia Chung wrote:
> >   This patch fixes a minor checkpatch warnings:
> > 
> >   "WARNING: Block comments use a trailing */ on a separate line"
> > 
> >   Signed-off-by: Ming-Chia Chung 
> > ---
> >  drivers/staging/rts5208/rtsx.c | 42 
> > --
> >  1 file changed, 28 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/staging/rts5208/rtsx.c b/drivers/staging/rts5208/rtsx.c
> > index e992e03..a880411 100644
> > --- a/drivers/staging/rts5208/rtsx.c
> > +++ b/drivers/staging/rts5208/rtsx.c
> > @@ -81,14 +81,16 @@ static int slave_alloc(struct scsi_device *sdev)
> >  
> >  static int slave_configure(struct scsi_device *sdev)
> >  {
> > -   /* Scatter-gather buffers (all but the last) must have a length
> > +   /*
> > +   * Scatter-gather buffers (all but the last) must have a length
> 
> The alignment doesnot look correct here. Also in some more places later
> in this patch.
> 
> regards
> Sudip

I sent this patch by following docs ([1] and [2]). The style for long
comments needs the begining and ending almost-blank lines. There is no
the begining almost-blank line only for the files in net/ and
drivers/net/.
Please let me know what I misunderstood.

[1]: Linux kernel coding style, ch. 8 Commenting
https://www.kernel.org/doc/Documentation/CodingStyle
[2]: Linus Torvalds on comment styles
https://lkml.org/lkml/2016/7/8/625

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


[RFC PATCH v1 23/28] KVM: SVM: add SEV launch update command

2016-08-22 Thread Brijesh Singh
The command is used for encrypting guest memory region.

For more information see [1], section 6.2

[1] http://support.amd.com/TechDocs/55766_SEV-KM%20API_Spec.pdf

Signed-off-by: Brijesh Singh 
---
 arch/x86/kvm/svm.c |  126 
 1 file changed, 126 insertions(+)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 0b6da4a..c78bdc6 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -35,6 +35,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -263,6 +265,8 @@ static unsigned long *sev_asid_bitmap;
 #define svm_sev_guest()(svm->vcpu.kvm->arch.sev_info.handle)
 #define svm_sev_ref_count()(svm->vcpu.kvm->arch.sev_info.ref_count)
 
+#define __sev_page_pa(x) ((page_to_pfn(x) << PAGE_SHIFT) | sme_me_mask)
+
 static int sev_asid_new(void);
 static void sev_asid_free(int asid);
 static void sev_deactivate_handle(unsigned int handle);
@@ -5376,6 +5380,123 @@ err_1:
return ret;
 }
 
+static int sev_pre_update(struct page **pages, unsigned long uaddr, int npages)
+{
+   int pinned;
+
+   /* pin the user virtual address */
+   down_read(>mm->mmap_sem);
+   pinned = get_user_pages(uaddr, npages, 1, 0, pages, NULL);
+   up_read(>mm->mmap_sem);
+   if (pinned != npages) {
+   printk(KERN_ERR "SEV: failed to pin  %d pages (got %d)\n",
+   npages, pinned);
+   goto err;
+   }
+
+   return 0;
+err:
+   if (pinned > 0)
+   release_pages(pages, pinned, 0);
+   return 1;
+}
+
+static int sev_launch_update(struct kvm *kvm,
+struct kvm_sev_launch_update __user *arg,
+int *psp_ret)
+{
+   int first, last;
+   struct page **inpages;
+   int ret, nr_pages;
+   unsigned long uaddr, ulen;
+   int i, buffer_len, len, offset;
+   struct kvm_sev_launch_update params;
+   struct psp_data_launch_update *update;
+
+   /* Get the parameters from the user */
+   if (copy_from_user(, arg, sizeof(*arg)))
+   return -EFAULT;
+
+   uaddr = params.address;
+   ulen = params.length;
+
+   /* Get number of pages */
+   first = (uaddr & PAGE_MASK) >> PAGE_SHIFT;
+   last = ((uaddr + ulen - 1) & PAGE_MASK) >> PAGE_SHIFT;
+   nr_pages = (last - first + 1);
+
+   /* allocate the buffers */
+   buffer_len = sizeof(*update);
+   update = kzalloc(buffer_len, GFP_KERNEL);
+   if (!update)
+   return -ENOMEM;
+
+   ret = -ENOMEM;
+   inpages = kzalloc(nr_pages * sizeof(struct page *), GFP_KERNEL);
+   if (!inpages)
+   goto err_1;
+
+   ret = sev_pre_update(inpages, uaddr, nr_pages);
+   if (ret)
+   goto err_2;
+
+   /* the array of pages returned by get_user_pages() is a page-aligned
+* memory. Since the user buffer is probably not page-aligned, we need
+* to calculate the offset within a page for first update entry.
+*/
+   offset = uaddr & (PAGE_SIZE - 1);
+   len = min_t(size_t, (PAGE_SIZE - offset), ulen);
+   ulen -= len;
+
+   /* update first page -
+* special care need to be taken for the first page because we might
+* be dealing with offset within the page
+*/
+   update->hdr.buffer_len = buffer_len;
+   update->handle = kvm_sev_handle();
+   update->length = len;
+   update->address = __sev_page_pa(inpages[0]) + offset;
+   clflush_cache_range(page_address(inpages[0]), PAGE_SIZE);
+   ret = psp_guest_launch_update(update, 5, psp_ret);
+   if (ret) {
+   printk(KERN_ERR "SEV: LAUNCH_UPDATE addr %#llx len %d "
+   "ret=%d (%#010x)\n", update->address,
+   update->length, ret, *psp_ret);
+   goto err_3;
+   }
+
+   /* update remaining pages */
+   for (i = 1; i < nr_pages; i++) {
+
+   len = min_t(size_t, PAGE_SIZE, ulen);
+   ulen -= len;
+   update->length = len;
+   update->address = __sev_page_pa(inpages[i]);
+   clflush_cache_range(page_address(inpages[i]), PAGE_SIZE);
+
+   ret = psp_guest_launch_update(update, 5, psp_ret);
+   if (ret) {
+   printk(KERN_ERR "SEV: LAUNCH_UPDATE addr %#llx len %d "
+   "ret=%d (%#010x)\n", update->address,
+   update->length, ret, *psp_ret);
+   goto err_3;
+   }
+   }
+
+err_3:
+   /* mark pages dirty */
+   for (i = 0; i < nr_pages; i++) {
+   set_page_dirty_lock(inpages[i]);
+   mark_page_accessed(inpages[i]);
+   }
+   release_pages(inpages, nr_pages, 0);
+err_2:
+   kfree(inpages);
+err_1:
+   kfree(update);
+   return ret;
+}
+ 
 

[RFC PATCH v1 14/28] x86: Don't set the SME MSR bit when SEV is active

2016-08-22 Thread Brijesh Singh
From: Tom Lendacky 

When SEV is active the virtual machine cannot set the MSR for SME, so
don't set the trampoline flag for SME.

Signed-off-by: Tom Lendacky 
---
 arch/x86/realmode/init.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/realmode/init.c b/arch/x86/realmode/init.c
index f3207e5..391d8ba 100644
--- a/arch/x86/realmode/init.c
+++ b/arch/x86/realmode/init.c
@@ -102,7 +102,7 @@ static void __init setup_real_mode(void)
*trampoline_cr4_features = mmu_cr4_features;
 
trampoline_header->flags = 0;
-   if (sme_me_mask)
+   if (sme_me_mask && !sev_active)
trampoline_header->flags |= TH_FLAGS_SME_ENABLE;
 
trampoline_pgd = (u64 *) __va(real_mode_header->trampoline_pgd);

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


[RFC PATCH v1 20/28] KVM: SVM: prepare for SEV guest management API support

2016-08-22 Thread Brijesh Singh
The patch adds initial support required for Secure Encrypted
Virtualization (SEV) guest management API's.

ASID management:
 - Reserve asid range for SEV guest, SEV asid range is obtained
   through CPUID Fn8000_001f[ECX]. A non-SEV guest can use any
   asid outside the SEV asid range.
 - SEV guest must have asid value within asid range obtained
   through CPUID.
 - SEV guest must have the same asid for all vcpu's. A TLB flush
   is required if different vcpu for the same ASID is to be run
   on the same host CPU.

- save SEV private structure in kvm_arch.

- If SEV is available then initialize PSP firmware during hardware probe

Signed-off-by: Brijesh Singh 
---
 arch/x86/include/asm/kvm_host.h |9 ++
 arch/x86/kvm/svm.c  |  213 +++
 2 files changed, 221 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index b1dd673..9b885fc 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -715,6 +715,12 @@ struct kvm_hv {
u64 hv_crash_ctl;
 };
 
+struct kvm_sev_info {
+   unsigned int asid;  /* asid for this guest */
+   unsigned int handle;/* firmware handle */
+   unsigned int ref_count; /* number of active vcpus */
+};
+
 struct kvm_arch {
unsigned int n_used_mmu_pages;
unsigned int n_requested_mmu_pages;
@@ -799,6 +805,9 @@ struct kvm_arch {
 
bool x2apic_format;
bool x2apic_broadcast_quirk_disabled;
+
+   /* struct for SEV guest */
+   struct kvm_sev_info sev_info;
 };
 
 struct kvm_vm_stat {
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index f010b23..dcee635 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -186,6 +187,9 @@ struct vcpu_svm {
struct page *avic_backing_page;
u64 *avic_physical_id_cache;
bool avic_is_running;
+
+   /* which host cpu was used for running this vcpu */
+   bool last_cpuid;
 };
 
 #define AVIC_LOGICAL_ID_ENTRY_GUEST_PHYSICAL_ID_MASK   (0xFF)
@@ -243,6 +247,25 @@ static int avic;
 module_param(avic, int, S_IRUGO);
 #endif
 
+/* Secure Encrypted Virtualization */
+static bool sev_enabled;
+static unsigned long max_sev_asid;
+static unsigned long *sev_asid_bitmap;
+
+#define kvm_sev_guest()(kvm->arch.sev_info.handle)
+#define kvm_sev_handle()   (kvm->arch.sev_info.handle)
+#define kvm_sev_ref()  (kvm->arch.sev_info.ref_count++)
+#define kvm_sev_unref()(kvm->arch.sev_info.ref_count--)
+#define svm_sev_handle()   (svm->vcpu.kvm->arch.sev_info.handle)
+#define svm_sev_asid() (svm->vcpu.kvm->arch.sev_info.asid)
+#define svm_sev_ref()  (svm->vcpu.kvm->arch.sev_info.ref_count++)
+#define svm_sev_unref()
(svm->vcpu.kvm->arch.sev_info.ref_count--)
+#define svm_sev_guest()(svm->vcpu.kvm->arch.sev_info.handle)
+#define svm_sev_ref_count()(svm->vcpu.kvm->arch.sev_info.ref_count)
+
+static int sev_asid_new(void);
+static void sev_asid_free(int asid);
+
 static void svm_set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0);
 static void svm_flush_tlb(struct kvm_vcpu *vcpu);
 static void svm_complete_interrupts(struct vcpu_svm *svm);
@@ -474,6 +497,8 @@ struct svm_cpu_data {
struct kvm_ldttss_desc *tss_desc;
 
struct page *save_area;
+
+   void **sev_vmcb;  /* index = sev_asid, value = vmcb pointer */
 };
 
 static DEFINE_PER_CPU(struct svm_cpu_data *, svm_data);
@@ -727,7 +752,10 @@ static int svm_hardware_enable(void)
sd->asid_generation = 1;
sd->max_asid = cpuid_ebx(SVM_CPUID_FUNC) - 1;
sd->next_asid = sd->max_asid + 1;
-   sd->min_asid = 1;
+   sd->min_asid = max_sev_asid + 1;
+
+   if (sev_enabled)
+   memset(sd->sev_vmcb, 0, (max_sev_asid + 1) * sizeof(void *));
 
native_store_gdt(_descr);
gdt = (struct desc_struct *)gdt_descr.address;
@@ -788,6 +816,7 @@ static void svm_cpu_uninit(int cpu)
 
per_cpu(svm_data, raw_smp_processor_id()) = NULL;
__free_page(sd->save_area);
+   kfree(sd->sev_vmcb);
kfree(sd);
 }
 
@@ -805,6 +834,14 @@ static int svm_cpu_init(int cpu)
if (!sd->save_area)
goto err_1;
 
+   if (sev_enabled) {
+   sd->sev_vmcb = kmalloc((max_sev_asid + 1) * sizeof(void *),
+   GFP_KERNEL);
+   r = -ENOMEM;
+   if (!sd->sev_vmcb)
+   goto err_1;
+   }
+
per_cpu(svm_data, cpu) = sd;
 
return 0;
@@ -931,6 +968,74 @@ static void svm_disable_lbrv(struct vcpu_svm *svm)
set_msr_interception(msrpm, MSR_IA32_LASTINTTOIP, 0, 0);
 }
 
+static __init void sev_hardware_setup(void)
+{
+   int ret, psp_ret;
+   struct psp_data_init *init;
+   struct psp_data_status *status;
+

[RFC PATCH v1 19/28] KVM: SVM: prepare to reserve asid for SEV guest

2016-08-22 Thread Brijesh Singh
In current implementation, asid allocation starts from 1, this patch
adds a min_asid variable in svm_vcpu structure to allow starting asid
from something other than 1.

Signed-off-by: Brijesh Singh 
---
 arch/x86/kvm/svm.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 211be94..f010b23 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -470,6 +470,7 @@ struct svm_cpu_data {
u64 asid_generation;
u32 max_asid;
u32 next_asid;
+   u32 min_asid;
struct kvm_ldttss_desc *tss_desc;
 
struct page *save_area;
@@ -726,6 +727,7 @@ static int svm_hardware_enable(void)
sd->asid_generation = 1;
sd->max_asid = cpuid_ebx(SVM_CPUID_FUNC) - 1;
sd->next_asid = sd->max_asid + 1;
+   sd->min_asid = 1;
 
native_store_gdt(_descr);
gdt = (struct desc_struct *)gdt_descr.address;
@@ -1887,7 +1889,7 @@ static void new_asid(struct vcpu_svm *svm, struct 
svm_cpu_data *sd)
 {
if (sd->next_asid > sd->max_asid) {
++sd->asid_generation;
-   sd->next_asid = 1;
+   sd->next_asid = sd->min_asid;
svm->vmcb->control.tlb_ctl = TLB_CONTROL_FLUSH_ALL_ASID;
}
 

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


[RFC PATCH v1 11/28] x86: Don't decrypt trampoline area if SEV is active

2016-08-22 Thread Brijesh Singh
From: Tom Lendacky 

When Secure Encrypted Virtualization is active instruction fetches are
always interpreted as being from encrypted memory so the trampoline area
must remain encrypted when SEV is active.

Signed-off-by: Tom Lendacky 
---
 arch/x86/realmode/init.c |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/x86/realmode/init.c b/arch/x86/realmode/init.c
index c3edb49..f3207e5 100644
--- a/arch/x86/realmode/init.c
+++ b/arch/x86/realmode/init.c
@@ -138,10 +138,13 @@ static void __init set_real_mode_permissions(void)
/*
 * If memory encryption is active, the trampoline area will need to
 * be in non-encrypted memory in order to bring up other processors
-* successfully.
+* successfully. This only applies to SME, SEV requires the trampoline
+* to be encrypted.
 */
-   sme_early_mem_dec(__pa(base), size);
-   sme_set_mem_dec(base, size);
+   if (!sev_active) {
+   sme_early_mem_dec(__pa(base), size);
+   sme_set_mem_dec(base, size);
+   }
 
set_memory_nx((unsigned long) base, size >> PAGE_SHIFT);
set_memory_ro((unsigned long) base, ro_size >> PAGE_SHIFT);

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


[RFC PATCH v1 10/28] x86: Change early_ioremap to early_memremap for BOOT data

2016-08-22 Thread Brijesh Singh
From: Tom Lendacky 

Signed-off-by: Tom Lendacky 
---
 arch/x86/kernel/acpi/boot.c |4 ++--
 arch/x86/kernel/mpparse.c   |   10 +-
 drivers/sfi/sfi_core.c  |6 +++---
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 1ad5fe2..4622ea2 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -120,7 +120,7 @@ char *__init __acpi_map_table(unsigned long phys, unsigned 
long size)
if (!phys || !size)
return NULL;
 
-   return early_ioremap(phys, size);
+   return early_memremap(phys, size, BOOT_DATA);
 }
 
 void __init __acpi_unmap_table(char *map, unsigned long size)
@@ -128,7 +128,7 @@ void __init __acpi_unmap_table(char *map, unsigned long 
size)
if (!map || !size)
return;
 
-   early_iounmap(map, size);
+   early_memunmap(map, size);
 }
 
 #ifdef CONFIG_X86_LOCAL_APIC
diff --git a/arch/x86/kernel/mpparse.c b/arch/x86/kernel/mpparse.c
index 0f8d204..04def9f 100644
--- a/arch/x86/kernel/mpparse.c
+++ b/arch/x86/kernel/mpparse.c
@@ -436,9 +436,9 @@ static unsigned long __init get_mpc_size(unsigned long 
physptr)
struct mpc_table *mpc;
unsigned long size;
 
-   mpc = early_ioremap(physptr, PAGE_SIZE);
+   mpc = early_memremap(physptr, PAGE_SIZE, BOOT_DATA);
size = mpc->length;
-   early_iounmap(mpc, PAGE_SIZE);
+   early_memunmap(mpc, PAGE_SIZE);
apic_printk(APIC_VERBOSE, "  mpc: %lx-%lx\n", physptr, physptr + size);
 
return size;
@@ -450,7 +450,7 @@ static int __init check_physptr(struct mpf_intel *mpf, 
unsigned int early)
unsigned long size;
 
size = get_mpc_size(mpf->physptr);
-   mpc = early_ioremap(mpf->physptr, size);
+   mpc = early_memremap(mpf->physptr, size, BOOT_DATA);
/*
 * Read the physical hardware table.  Anything here will
 * override the defaults.
@@ -461,10 +461,10 @@ static int __init check_physptr(struct mpf_intel *mpf, 
unsigned int early)
 #endif
pr_err("BIOS bug, MP table errors detected!...\n");
pr_cont("... disabling SMP support. (tell your hw vendor)\n");
-   early_iounmap(mpc, size);
+   early_memunmap(mpc, size);
return -1;
}
-   early_iounmap(mpc, size);
+   early_memunmap(mpc, size);
 
if (early)
return -1;
diff --git a/drivers/sfi/sfi_core.c b/drivers/sfi/sfi_core.c
index 296db7a..3078d35 100644
--- a/drivers/sfi/sfi_core.c
+++ b/drivers/sfi/sfi_core.c
@@ -92,7 +92,7 @@ static struct sfi_table_simple *syst_va __read_mostly;
 static u32 sfi_use_ioremap __read_mostly;
 
 /*
- * sfi_un/map_memory calls early_ioremap/iounmap which is a __init function
+ * sfi_un/map_memory calls early_memremap/memunmap which is a __init function
  * and introduces section mismatch. So use __ref to make it calm.
  */
 static void __iomem * __ref sfi_map_memory(u64 phys, u32 size)
@@ -103,7 +103,7 @@ static void __iomem * __ref sfi_map_memory(u64 phys, u32 
size)
if (sfi_use_ioremap)
return ioremap_cache(phys, size);
else
-   return early_ioremap(phys, size);
+   return early_memremap(phys, size, BOOT_DATA);
 }
 
 static void __ref sfi_unmap_memory(void __iomem *virt, u32 size)
@@ -114,7 +114,7 @@ static void __ref sfi_unmap_memory(void __iomem *virt, u32 
size)
if (sfi_use_ioremap)
iounmap(virt);
else
-   early_iounmap(virt, size);
+   early_memunmap(virt, size);
 }
 
 static void sfi_print_table_header(unsigned long long pa,

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


[RFC PATCH v1 13/28] iommu/amd: AMD IOMMU support for SEV

2016-08-22 Thread Brijesh Singh
From: Tom Lendacky 

DMA must be performed to memory that is not mapped encrypted when running
with SEV active. So if SEV is active, do not return the encryption mask
to the IOMMU.

Signed-off-by: Tom Lendacky 
---
 arch/x86/mm/mem_encrypt.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index ce6e3ea..d6e9f96 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -237,7 +237,7 @@ void __init mem_encrypt_init(void)
 
 unsigned long amd_iommu_get_me_mask(void)
 {
-   return sme_me_mask;
+   return sev_active ? 0 : sme_me_mask;
 }
 
 unsigned long swiotlb_get_me_mask(void)

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


[RFC PATCH v1 06/28] KVM: SVM: Add SEV feature definitions to KVM

2016-08-22 Thread Brijesh Singh
From: Tom Lendacky 

Define a new KVM cpu feature for Secure Encrypted Virtualization (SEV).
The kernel will check for the presence of this feature to determine if
it is running with SEV active.

Define the SEV enable bit for the VMCB control structure. The hypervisor
will use this bit to enable SEV in the guest.

Signed-off-by: Tom Lendacky 
---
 arch/x86/include/asm/svm.h   |1 +
 arch/x86/include/uapi/asm/kvm_para.h |1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index 2aca535..fba2a7b 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -137,6 +137,7 @@ struct __attribute__ ((__packed__)) vmcb_control_area {
 #define SVM_VM_CR_SVM_DIS_MASK  0x0010ULL
 
 #define SVM_NESTED_CTL_NP_ENABLE   BIT(0)
+#define SVM_NESTED_CTL_SEV_ENABLE  BIT(1)
 
 struct __attribute__ ((__packed__)) vmcb_seg {
u16 selector;
diff --git a/arch/x86/include/uapi/asm/kvm_para.h 
b/arch/x86/include/uapi/asm/kvm_para.h
index 94dc8ca..67dd610f 100644
--- a/arch/x86/include/uapi/asm/kvm_para.h
+++ b/arch/x86/include/uapi/asm/kvm_para.h
@@ -24,6 +24,7 @@
 #define KVM_FEATURE_STEAL_TIME 5
 #define KVM_FEATURE_PV_EOI 6
 #define KVM_FEATURE_PV_UNHALT  7
+#define KVM_FEATURE_SEV8
 
 /* The last 8 bits are used to indicate how to interpret the flags field
  * in pvclock structure. If no bits are set, all flags are ignored.

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


[RFC PATCH v1 01/28] kvm: svm: Add support for additional SVM NPF error codes

2016-08-22 Thread Brijesh Singh
From: Tom Lendacky 

AMD hardware adds two additional bits to aid in nested page fault handling.

Bit 32 - NPF occurred while translating the guest's final physical address
Bit 33 - NPF occurred while translating the guest page tables

The guest page tables fault indicator can be used as an aid for nested
virtualization. Using V0 for the host, V1 for the first level guest and
V2 for the second level guest, when both V1 and V2 are using nested paging
there are currently a number of unnecessary instruction emulations. When
V2 is launched shadow paging is used in V1 for the nested tables of V2. As
a result, KVM marks these pages as RO in the host nested page tables. When
V2 exits and we resume V1, these pages are still marked RO.

Every nested walk for a guest page table is treated as a user-level write
access and this causes a lot of NPFs because the V1 page tables are marked
RO in the V0 nested tables. While executing V1, when these NPFs occur KVM
sees a write to a read-only page, emulates the V1 instruction and unprotects
the page (marking it RW). This patch looks for cases where we get a NPF due
to a guest page table walk where the page was marked RO. It immediately
unprotects the page and resumes the guest, leading to far fewer instruction
emulations when nested virtualization is used.

Signed-off-by: Tom Lendacky 
---
 arch/x86/include/asm/kvm_host.h |   11 ++-
 arch/x86/kvm/mmu.c  |   20 ++--
 arch/x86/kvm/svm.c  |2 +-
 3 files changed, 29 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index c51c1cb..3f05d36 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -191,6 +191,8 @@ enum {
 #define PFERR_RSVD_BIT 3
 #define PFERR_FETCH_BIT 4
 #define PFERR_PK_BIT 5
+#define PFERR_GUEST_FINAL_BIT 32
+#define PFERR_GUEST_PAGE_BIT 33
 
 #define PFERR_PRESENT_MASK (1U << PFERR_PRESENT_BIT)
 #define PFERR_WRITE_MASK (1U << PFERR_WRITE_BIT)
@@ -198,6 +200,13 @@ enum {
 #define PFERR_RSVD_MASK (1U << PFERR_RSVD_BIT)
 #define PFERR_FETCH_MASK (1U << PFERR_FETCH_BIT)
 #define PFERR_PK_MASK (1U << PFERR_PK_BIT)
+#define PFERR_GUEST_FINAL_MASK (1ULL << PFERR_GUEST_FINAL_BIT)
+#define PFERR_GUEST_PAGE_MASK (1ULL << PFERR_GUEST_PAGE_BIT)
+
+#define PFERR_NESTED_GUEST_PAGE (PFERR_GUEST_PAGE_MASK |   \
+PFERR_USER_MASK |  \
+PFERR_WRITE_MASK | \
+PFERR_PRESENT_MASK)
 
 /* apic attention bits */
 #define KVM_APIC_CHECK_VAPIC   0
@@ -1203,7 +1212,7 @@ void kvm_vcpu_deactivate_apicv(struct kvm_vcpu *vcpu);
 
 int kvm_emulate_hypercall(struct kvm_vcpu *vcpu);
 
-int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva, u32 error_code,
+int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva, u64 error_code,
   void *insn, int insn_len);
 void kvm_mmu_invlpg(struct kvm_vcpu *vcpu, gva_t gva);
 void kvm_mmu_new_cr3(struct kvm_vcpu *vcpu);
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index a7040f4..3b47a5d 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4512,7 +4512,7 @@ static void make_mmu_pages_available(struct kvm_vcpu 
*vcpu)
kvm_mmu_commit_zap_page(vcpu->kvm, _list);
 }
 
-int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t cr2, u32 error_code,
+int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t cr2, u64 error_code,
   void *insn, int insn_len)
 {
int r, emulation_type = EMULTYPE_RETRY;
@@ -4531,12 +4531,28 @@ int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t 
cr2, u32 error_code,
return r;
}
 
-   r = vcpu->arch.mmu.page_fault(vcpu, cr2, error_code, false);
+   r = vcpu->arch.mmu.page_fault(vcpu, cr2, lower_32_bits(error_code),
+ false);
if (r < 0)
return r;
if (!r)
return 1;
 
+   /*
+* Before emulating the instruction, check if the error code
+* was due to a RO violation while translating the guest page.
+* This can occur when using nested virtualization with nested
+* paging in both guests. If true, we simply unprotect the page
+* and resume the guest.
+*
+* Note: AMD only (since it supports the PFERR_GUEST_PAGE_MASK used
+*   in PFERR_NEXT_GUEST_PAGE)
+*/
+   if (error_code == PFERR_NESTED_GUEST_PAGE) {
+   kvm_mmu_unprotect_page(vcpu->kvm, gpa_to_gfn(cr2));
+   return 1;
+   }
+
if (mmio_info_in_cache(vcpu, cr2, direct))
emulation_type = 0;
 emulate:
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 1e6b84b..d8b9c8c 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1935,7 +1935,7 @@ static void svm_set_dr7(struct kvm_vcpu *vcpu, unsigned 
long 

[RFC PATCH v1 08/28] Access BOOT related data encrypted with SEV active

2016-08-22 Thread Brijesh Singh
From: Tom Lendacky 

When Secure Encrypted Virtualization (SEV) is active, BOOT data (such as
EFI related data) is encrypted and needs to be access as such. Update the
architecture override in early_memremap to keep the encryption attribute
when mapping this data.

Signed-off-by: Tom Lendacky 
---
 arch/x86/mm/ioremap.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index e3bdc5a..2ea6deb 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -429,10 +429,11 @@ pgprot_t __init 
early_memremap_pgprot_adjust(resource_size_t phys_addr,
 pgprot_t prot)
 {
/*
-* If memory encryption is enabled and BOOT_DATA is being mapped
-* then remove the encryption bit.
+* If memory encryption is enabled, we are not running with
+* SEV active and BOOT_DATA is being mapped then remove the
+* encryption bit
 */
-   if (_PAGE_ENC && (owner == BOOT_DATA))
+   if (_PAGE_ENC && !sev_active && (owner == BOOT_DATA))
prot = __pgprot(pgprot_val(prot) & ~_PAGE_ENC);
 
return prot;

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


[RFC PATCH v1 12/28] x86: DMA support for SEV memory encryption

2016-08-22 Thread Brijesh Singh
From: Tom Lendacky 

DMA access to memory mapped as encrypted while SEV is active can not be
encrypted during device write or decrypted during device read. In order
for DMA to properly work when SEV is active, the swiotlb bounce buffers
must be used.

Signed-off-by: Tom Lendacky 
---
 arch/x86/mm/mem_encrypt.c |   48 +
 1 file changed, 48 insertions(+)

diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index 1154353..ce6e3ea 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -173,8 +173,52 @@ void __init sme_early_init(void)
/* Update the protection map with memory encryption mask */
for (i = 0; i < ARRAY_SIZE(protection_map); i++)
protection_map[i] = __pgprot(pgprot_val(protection_map[i]) | 
sme_me_mask);
+
+   if (sev_active)
+   swiotlb_force = 1;
 }
 
+static void *sme_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
+  gfp_t gfp, unsigned long attrs)
+{
+   void *vaddr;
+
+   vaddr = x86_swiotlb_alloc_coherent(dev, size, dma_handle, gfp, attrs);
+   if (!vaddr)
+   return NULL;
+
+   /* Clear the SME encryption bit for DMA use */
+   sme_set_mem_dec(vaddr, size);
+
+   /* Remove the encryption bit from the DMA address */
+   *dma_handle &= ~sme_me_mask;
+
+   return vaddr;
+}
+
+static void sme_free(struct device *dev, size_t size, void *vaddr,
+dma_addr_t dma_handle, unsigned long attrs)
+{
+   /* Set the SME encryption bit for re-use as encrypted */
+   sme_set_mem_enc(vaddr, size);
+
+   x86_swiotlb_free_coherent(dev, size, vaddr, dma_handle, attrs);
+}
+
+static struct dma_map_ops sme_dma_ops = {
+   .alloc  = sme_alloc,
+   .free   = sme_free,
+   .map_page   = swiotlb_map_page,
+   .unmap_page = swiotlb_unmap_page,
+   .map_sg = swiotlb_map_sg_attrs,
+   .unmap_sg   = swiotlb_unmap_sg_attrs,
+   .sync_single_for_cpu= swiotlb_sync_single_for_cpu,
+   .sync_single_for_device = swiotlb_sync_single_for_device,
+   .sync_sg_for_cpu= swiotlb_sync_sg_for_cpu,
+   .sync_sg_for_device = swiotlb_sync_sg_for_device,
+   .mapping_error  = swiotlb_dma_mapping_error,
+};
+
 /* Architecture __weak replacement functions */
 void __init mem_encrypt_init(void)
 {
@@ -184,6 +228,10 @@ void __init mem_encrypt_init(void)
/* Make SWIOTLB use an unencrypted DMA area */
swiotlb_clear_encryption();
 
+   /* Use SEV DMA operations if SEV is active */
+   if (sev_active)
+   dma_ops = _dma_ops;
+
pr_info("memory encryption active\n");
 }
 

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


[RFC PATCH v1 04/28] x86: Secure Encrypted Virtualization (SEV) support

2016-08-22 Thread Brijesh Singh
From: Tom Lendacky 

Provide support for Secure Encyrpted Virtualization (SEV). This initial
support defines the SEV active flag in order for the kernel to determine
if it is running with SEV active or not.

Signed-off-by: Tom Lendacky 
---
 arch/x86/include/asm/mem_encrypt.h |3 +++
 arch/x86/kernel/mem_encrypt.S  |8 
 arch/x86/kernel/x8664_ksyms_64.c   |1 +
 3 files changed, 12 insertions(+)

diff --git a/arch/x86/include/asm/mem_encrypt.h 
b/arch/x86/include/asm/mem_encrypt.h
index e395729..9c592d1 100644
--- a/arch/x86/include/asm/mem_encrypt.h
+++ b/arch/x86/include/asm/mem_encrypt.h
@@ -20,6 +20,7 @@
 #ifdef CONFIG_AMD_MEM_ENCRYPT
 
 extern unsigned long sme_me_mask;
+extern unsigned int sev_active;
 
 u8 sme_get_me_loss(void);
 
@@ -50,6 +51,8 @@ void swiotlb_set_mem_dec(void *vaddr, unsigned long size);
 
 #define sme_me_mask0UL
 
+#define sev_active 0
+
 static inline u8 sme_get_me_loss(void)
 {
return 0;
diff --git a/arch/x86/kernel/mem_encrypt.S b/arch/x86/kernel/mem_encrypt.S
index bf9f6a9..6a8cd18 100644
--- a/arch/x86/kernel/mem_encrypt.S
+++ b/arch/x86/kernel/mem_encrypt.S
@@ -96,6 +96,10 @@ ENDPROC(sme_enable)
 
 ENTRY(sme_encrypt_kernel)
 #ifdef CONFIG_AMD_MEM_ENCRYPT
+   /* If SEV is active then the kernel is already encrypted */
+   cmpl$0, sev_active(%rip)
+   jnz .Lencrypt_exit
+
/* If SME is not active then no need to encrypt the kernel */
cmpq$0, sme_me_mask(%rip)
jz  .Lencrypt_exit
@@ -334,6 +338,10 @@ sme_me_loss:
.byte   0x00
.align  8
 
+ENTRY(sev_active)
+   .word   0x
+   .align  8
+
 mem_encrypt_enable_option:
.asciz "mem_encrypt=on"
.align  8
diff --git a/arch/x86/kernel/x8664_ksyms_64.c b/arch/x86/kernel/x8664_ksyms_64.c
index 651c4c8..14bfc0b 100644
--- a/arch/x86/kernel/x8664_ksyms_64.c
+++ b/arch/x86/kernel/x8664_ksyms_64.c
@@ -88,4 +88,5 @@ EXPORT_SYMBOL(___preempt_schedule_notrace);
 #ifdef CONFIG_AMD_MEM_ENCRYPT
 EXPORT_SYMBOL_GPL(sme_me_mask);
 EXPORT_SYMBOL_GPL(sme_get_me_loss);
+EXPORT_SYMBOL_GPL(sev_active);
 #endif

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


[RFC PATCH v1 05/28] KVM: SVM: prepare for new bit definition in nested_ctl

2016-08-22 Thread Brijesh Singh
From: Tom Lendacky 

Currently the nested_ctl variable in the vmcb_control_area structure is
used to indicate nested paging support. The nested paging support field
is actually defined as bit 0 of the this field. In order to support a new
feature flag the usage of the nested_ctl and nested paging support must
be converted to operate on a single bit.

Signed-off-by: Tom Lendacky 
---
 arch/x86/include/asm/svm.h |2 ++
 arch/x86/kvm/svm.c |7 ---
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index 14824fc..2aca535 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -136,6 +136,8 @@ struct __attribute__ ((__packed__)) vmcb_control_area {
 #define SVM_VM_CR_SVM_LOCK_MASK 0x0008ULL
 #define SVM_VM_CR_SVM_DIS_MASK  0x0010ULL
 
+#define SVM_NESTED_CTL_NP_ENABLE   BIT(0)
+
 struct __attribute__ ((__packed__)) vmcb_seg {
u16 selector;
u16 attrib;
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 9b2de7c..9b59260 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1177,7 +1177,7 @@ static void init_vmcb(struct vcpu_svm *svm)
 
if (npt_enabled) {
/* Setup VMCB for Nested Paging */
-   control->nested_ctl = 1;
+   control->nested_ctl |= SVM_NESTED_CTL_NP_ENABLE;
clr_intercept(svm, INTERCEPT_INVLPG);
clr_exception_intercept(svm, PF_VECTOR);
clr_cr_intercept(svm, INTERCEPT_CR3_READ);
@@ -2701,7 +2701,8 @@ static bool nested_vmcb_checks(struct vmcb *vmcb)
if (vmcb->control.asid == 0)
return false;
 
-   if (vmcb->control.nested_ctl && !npt_enabled)
+   if ((vmcb->control.nested_ctl & SVM_NESTED_CTL_NP_ENABLE) &&
+   !npt_enabled)
return false;
 
return true;
@@ -2776,7 +2777,7 @@ static bool nested_svm_vmrun(struct vcpu_svm *svm)
else
svm->vcpu.arch.hflags &= ~HF_HIF_MASK;
 
-   if (nested_vmcb->control.nested_ctl) {
+   if (nested_vmcb->control.nested_ctl & SVM_NESTED_CTL_NP_ENABLE) {
kvm_mmu_unload(>vcpu);
svm->nested.nested_cr3 = nested_vmcb->control.nested_cr3;
nested_svm_init_mmu_context(>vcpu);

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


[RFC PATCH v1 26/28] KVM: SVM: add KVM_SEV_DEBUG_DECRYPT command

2016-08-22 Thread Brijesh Singh
The command decrypts a page of guest memory for debugging purposes.

For more information see [1], section 7.1

[1] http://support.amd.com/TechDocs/55766_SEV-KM%20API_Spec.pdf

Signed-off-by: Brijesh Singh 
---
 arch/x86/kvm/svm.c |   83 
 1 file changed, 83 insertions(+)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 63e7d15..b383bc7 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -5606,6 +5606,84 @@ err_1:
return ret;
 }
 
+static int __sev_dbg_decrypt_page(struct kvm *kvm, unsigned long src,
+ void *dst, int *psp_ret)
+{
+   int ret, pinned;
+   struct page **inpages;
+   struct psp_data_dbg *decrypt;
+
+   decrypt = kzalloc(sizeof(*decrypt), GFP_KERNEL);
+   if (!decrypt)
+   return -ENOMEM;
+
+   ret = -ENOMEM;
+   inpages = kzalloc(1 * sizeof(struct page *), GFP_KERNEL);
+   if (!inpages)
+   goto err_1;
+
+   /* pin the user virtual address */
+   ret = -EFAULT;
+   down_read(>mm->mmap_sem);
+   pinned = get_user_pages(src, 1, 1, 0, inpages, NULL);
+   up_read(>mm->mmap_sem);
+   if (pinned < 0)
+   goto err_2;
+
+   decrypt->hdr.buffer_len = sizeof(*decrypt);
+   decrypt->handle = kvm_sev_handle();
+   decrypt->dst_addr = __pa(dst) | sme_me_mask;
+   decrypt->src_addr = __sev_page_pa(inpages[0]);
+   decrypt->length = PAGE_SIZE;
+
+   ret = psp_dbg_decrypt(decrypt, psp_ret);
+   if (ret)
+   printk(KERN_ERR "SEV: DEBUG_DECRYPT %d (%#010x)\n",
+   ret, *psp_ret);
+   release_pages(inpages, 1, 0);
+err_2:
+   kfree(inpages);
+err_1:
+   kfree(decrypt);
+   return ret;
+}
+
+static int sev_dbg_decrypt(struct kvm *kvm,
+  struct kvm_sev_dbg_decrypt __user *argp,
+  int *psp_ret)
+{
+   void *data;
+   int ret, offset, len;
+   struct kvm_sev_dbg_decrypt debug;
+
+   if (!kvm_sev_guest())
+   return -ENOTTY;
+
+   if (copy_from_user(, argp, sizeof(*argp)))
+   return -EFAULT;
+
+   if (debug.length > PAGE_SIZE)
+   return -EINVAL;
+
+   data = (void *) get_zeroed_page(GFP_KERNEL);
+   if (!data)
+   return -ENOMEM;
+
+   /* decrypt one page */
+   ret = __sev_dbg_decrypt_page(kvm, debug.src_addr, data, psp_ret);
+   if (ret)
+   goto err_1;
+
+   /* we have decrypted full page but copy request length */
+   offset = debug.src_addr & (PAGE_SIZE - 1);
+   len = min_t(size_t, (PAGE_SIZE - offset), debug.length);
+   if (copy_to_user((uint8_t *)debug.dst_addr, data + offset, len))
+   ret = -EFAULT;
+err_1:
+   free_page((unsigned long)data);
+   return ret;
+}
+
 static int amd_sev_issue_cmd(struct kvm *kvm,
 struct kvm_sev_issue_cmd __user *user_data)
 {
@@ -5636,6 +5714,11 @@ static int amd_sev_issue_cmd(struct kvm *kvm,
_code);
break;
}
+   case KVM_SEV_DBG_DECRYPT: {
+   r = sev_dbg_decrypt(kvm, (void *)arg.opaque,
+   _code);
+   break;
+   }
default:
break;
}

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


[RFC PATCH v1 27/28] KVM: SVM: add KVM_SEV_DEBUG_ENCRYPT command

2016-08-22 Thread Brijesh Singh
The command encrypts a region of guest memory for debugging purposes.

For more information see [1], section 7.2

[1] http://support.amd.com/TechDocs/55766_SEV-KM%20API_Spec.pdf

Signed-off-by: Brijesh Singh 
---
 arch/x86/kvm/svm.c |  100 
 1 file changed, 100 insertions(+)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index b383bc7..4af195d 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -5684,6 +5684,101 @@ err_1:
return ret;
 }
 
+static int sev_dbg_encrypt(struct kvm *kvm,
+  struct kvm_sev_dbg_encrypt __user *argp,
+  int *psp_ret)
+{
+   void *data;
+   int len, ret, d_off;
+   struct page **inpages;
+   struct psp_data_dbg *encrypt;
+   struct kvm_sev_dbg_encrypt debug;
+   unsigned long src_addr, dst_addr;
+
+   if (!kvm_sev_guest())
+   return -ENOTTY;
+
+   if (copy_from_user(, argp, sizeof(*argp)))
+   return -EFAULT;
+
+   if (debug.length > PAGE_SIZE)
+   return -EINVAL;
+
+   len = debug.length;
+   src_addr = debug.src_addr;
+   dst_addr = debug.dst_addr;
+
+   inpages = kzalloc(1 * sizeof(struct page *), GFP_KERNEL);
+   if (!inpages)
+   return -ENOMEM;
+
+   /* pin the guest destination virtual address */
+   down_read(>mm->mmap_sem);
+   ret = get_user_pages(dst_addr, 1, 1, 0, inpages, NULL);
+   up_read(>mm->mmap_sem);
+   if (ret < 0)
+   goto err_1;
+
+   encrypt = kzalloc(sizeof(*encrypt), GFP_KERNEL);
+   if (!encrypt)
+   goto err_2;
+
+   data = (void *) get_zeroed_page(GFP_KERNEL);
+   if (!data)
+   goto err_3;
+
+   encrypt->hdr.buffer_len = sizeof(*encrypt);
+   encrypt->handle = kvm_sev_handle();
+
+   if ((len & 15) || (dst_addr & 15)) {
+   /* if destination address and length are not 16-byte
+* aligned then:
+* a) decrypt destination page into temporary buffer
+* b) copy source data into temporary buffer at correct offset
+* c) encrypt temporary buffer
+*/
+   ret = __sev_dbg_decrypt_page(kvm, dst_addr, data, psp_ret);
+   if (ret)
+   goto err_4;
+
+   d_off = dst_addr & (PAGE_SIZE - 1);
+   ret = -EFAULT;
+   if (copy_from_user(data + d_off,
+   (uint8_t *)debug.src_addr, len))
+   goto err_4;
+
+   encrypt->length = PAGE_SIZE;
+   encrypt->src_addr = __pa(data) | sme_me_mask;
+   encrypt->dst_addr =  __sev_page_pa(inpages[0]);
+   } else {
+   if (copy_from_user(data, (uint8_t *)debug.src_addr, len))
+   goto err_4;
+
+   d_off = dst_addr & (PAGE_SIZE - 1);
+   encrypt->length = len;
+   encrypt->src_addr = __pa(data) | sme_me_mask;
+   encrypt->dst_addr = __sev_page_pa(inpages[0]);
+   encrypt->dst_addr += d_off;
+   }
+
+   ret = psp_dbg_encrypt(encrypt, psp_ret);
+   if (ret)
+   printk(KERN_ERR "SEV: DEBUG_ENCRYPT: [%#lx=>%#lx+%#x] "
+   "%d (%#010x)\n",src_addr, dst_addr, len,
+   ret, *psp_ret);
+
+err_4:
+   free_page((unsigned long)data);
+err_3:
+   kfree(encrypt);
+err_2:
+   release_pages(inpages, 1, 0);
+err_1:
+   kfree(inpages);
+
+   return ret;
+}
+
 static int amd_sev_issue_cmd(struct kvm *kvm,
 struct kvm_sev_issue_cmd __user *user_data)
 {
@@ -5719,6 +5814,11 @@ static int amd_sev_issue_cmd(struct kvm *kvm,
_code);
break;
}
+   case KVM_SEV_DBG_ENCRYPT: {
+   r = sev_dbg_encrypt(kvm, (void *)arg.opaque,
+   _code);
+   break;
+   }
default:
break;
}

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


[RFC PATCH v1 16/28] x86: Add support to determine if running with SEV enabled

2016-08-22 Thread Brijesh Singh
From: Tom Lendacky 

Early in the boot process, add a check to determine if the kernel is
running with Secure Encrypted Virtualization (SEV) enabled. If active,
the kernel will perform steps necessary to insure the proper kernel
initialization process is performed.

Signed-off-by: Tom Lendacky 
---
 arch/x86/boot/compressed/Makefile  |2 +
 arch/x86/boot/compressed/head_64.S |   19 +
 arch/x86/boot/compressed/mem_encrypt.S |  123 
 arch/x86/include/uapi/asm/hyperv.h |4 +
 arch/x86/include/uapi/asm/kvm_para.h   |3 +
 arch/x86/kernel/mem_encrypt.S  |   36 +
 6 files changed, 187 insertions(+)
 create mode 100644 arch/x86/boot/compressed/mem_encrypt.S

diff --git a/arch/x86/boot/compressed/Makefile 
b/arch/x86/boot/compressed/Makefile
index 536ccfc..4888df9 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -73,6 +73,8 @@ vmlinux-objs-y := $(obj)/vmlinux.lds $(obj)/head_$(BITS).o 
$(obj)/misc.o \
$(obj)/string.o $(obj)/cmdline.o $(obj)/error.o \
$(obj)/piggy.o $(obj)/cpuflags.o
 
+vmlinux-objs-$(CONFIG_X86_64) += $(obj)/mem_encrypt.o
+
 vmlinux-objs-$(CONFIG_EARLY_PRINTK) += $(obj)/early_serial_console.o
 vmlinux-objs-$(CONFIG_RANDOMIZE_BASE) += $(obj)/kaslr.o
 ifdef CONFIG_X86_64
diff --git a/arch/x86/boot/compressed/head_64.S 
b/arch/x86/boot/compressed/head_64.S
index 0d80a7a..acb907a 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -131,6 +131,19 @@ ENTRY(startup_32)
  /*
   * Build early 4G boot pagetable
   */
+   /*
+* If SEV is active set the encryption mask in the page tables. This
+* will insure that when the kernel is copied and decompressed it
+* will be done so encrypted.
+*/
+   callsev_active
+   xorl%edx, %edx
+   testl   %eax, %eax
+   jz  1f
+   subl$32, %eax   /* Encryption bit is always above bit 31 */
+   bts %eax, %edx  /* Set encryption mask for page tables */
+1:
+
/* Initialize Page tables to 0 */
lealpgtable(%ebx), %edi
xorl%eax, %eax
@@ -141,12 +154,14 @@ ENTRY(startup_32)
lealpgtable + 0(%ebx), %edi
leal0x1007 (%edi), %eax
movl%eax, 0(%edi)
+   addl%edx, 4(%edi)
 
/* Build Level 3 */
lealpgtable + 0x1000(%ebx), %edi
leal0x1007(%edi), %eax
movl$4, %ecx
 1: movl%eax, 0x00(%edi)
+   addl%edx, 0x04(%edi)
addl$0x1000, %eax
addl$8, %edi
decl%ecx
@@ -157,6 +172,7 @@ ENTRY(startup_32)
movl$0x0183, %eax
movl$2048, %ecx
 1: movl%eax, 0(%edi)
+   addl%edx, 4(%edi)
addl$0x0020, %eax
addl$8, %edi
decl%ecx
@@ -344,6 +360,9 @@ preferred_addr:
subl$_end, %ebx
addq%rbp, %rbx
 
+   /* Check for SEV and adjust page tables as necessary */
+   callsev_adjust
+
/* Set up the stack */
leaqboot_stack_end(%rbx), %rsp
 
diff --git a/arch/x86/boot/compressed/mem_encrypt.S 
b/arch/x86/boot/compressed/mem_encrypt.S
new file mode 100644
index 000..56e19f6
--- /dev/null
+++ b/arch/x86/boot/compressed/mem_encrypt.S
@@ -0,0 +1,123 @@
+/*
+ * AMD Memory Encryption Support
+ *
+ * Copyright (C) 2016 Advanced Micro Devices, Inc.
+ *
+ * Author: Tom Lendacky 
+ *
+ * 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.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+   .text
+   .code32
+ENTRY(sev_active)
+   xor %eax, %eax
+
+#ifdef CONFIG_AMD_MEM_ENCRYPT
+   push%ebx
+   push%ecx
+   push%edx
+
+   /* Check if running under a hypervisor */
+   movl$0x4000, %eax
+   cpuid
+   cmpl$0x4001, %eax
+   jb  .Lno_sev
+
+   movl$0x4001, %eax
+   cpuid
+   bt  $KVM_FEATURE_SEV, %eax
+   jnc .Lno_sev
+
+   /*
+* Check for memory encryption feature:
+*   CPUID Fn8000_001F[EAX] - Bit 0
+*/
+   movl$0x801f, %eax
+   cpuid
+   bt  $0, %eax
+   jnc .Lno_sev
+
+   /*
+* Get memory encryption information:
+*   CPUID Fn8000_001F[EBX] - Bits 5:0
+* Pagetable bit position used to indicate encryption
+*/
+   movl%ebx, %eax
+   andl$0x3f, %eax
+   jmp .Lsev_exit
+
+.Lno_sev:
+   xor %eax, %eax
+
+.Lsev_exit:
+   pop %edx
+   pop %ecx
+   pop %ebx
+
+#endif /* CONFIG_AMD_MEM_ENCRYPT */
+
+   ret
+ENDPROC(sev_active)
+
+   .code64
+ENTRY(sev_adjust)
+#ifdef 

[RFC PATCH v1 22/28] KVM: SVM: add SEV launch start command

2016-08-22 Thread Brijesh Singh
The command initate the process to launch this guest into
SEV-enabled mode.

For more information on command structure see [1], section 6.1

[1] http://support.amd.com/TechDocs/55766_SEV-KM%20API_Spec.pdf

Signed-off-by: Brijesh Singh 
---
 arch/x86/kvm/svm.c |  212 +++-
 1 file changed, 209 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index dcee635..0b6da4a 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -265,6 +265,9 @@ static unsigned long *sev_asid_bitmap;
 
 static int sev_asid_new(void);
 static void sev_asid_free(int asid);
+static void sev_deactivate_handle(unsigned int handle);
+static void sev_decommission_handle(unsigned int handle);
+static int sev_activate_asid(unsigned int handle, int asid, int *psp_ret);
 
 static void svm_set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0);
 static void svm_flush_tlb(struct kvm_vcpu *vcpu);
@@ -1645,9 +1648,18 @@ static void sev_uninit_vcpu(struct vcpu_svm *svm)
 
svm_sev_unref();
 
-   for_each_possible_cpu(cpu) {
-   sd = per_cpu(svm_data, cpu);
-   sd->sev_vmcb[asid] = NULL;
+   /* when reference count reaches to zero then free SEV asid and
+* deactivate psp handle
+*/
+   if (!svm_sev_ref_count()) {
+   sev_deactivate_handle(svm_sev_handle());
+   sev_decommission_handle(svm_sev_handle());
+   sev_asid_free(svm_sev_asid());
+
+   for_each_possible_cpu(cpu) {
+   sd = per_cpu(svm_data, cpu);
+   sd->sev_vmcb[asid] = NULL;
+   }
}
 }
 
@@ -5196,6 +5208,198 @@ static void sev_asid_free(int asid)
clear_bit(asid, sev_asid_bitmap);
 }
 
+static void sev_decommission_handle(unsigned int handle)
+{
+   int ret, psp_ret;
+   struct psp_data_decommission *decommission;
+
+   decommission = kzalloc(sizeof(*decommission), GFP_KERNEL);
+   if (!decommission)
+   return;
+
+   decommission->hdr.buffer_len = sizeof(*decommission);
+   decommission->handle = handle;
+   ret = psp_guest_decommission(decommission, _ret);
+   if (ret)
+   printk(KERN_ERR "SEV: DECOMISSION ret=%d (%#010x)\n",
+   ret, psp_ret);
+
+   kfree(decommission);
+}
+
+static void sev_deactivate_handle(unsigned int handle)
+{
+   int ret, psp_ret;
+   struct psp_data_deactivate *deactivate;
+
+   deactivate = kzalloc(sizeof(*deactivate), GFP_KERNEL);
+   if (!deactivate)
+   return;
+
+   deactivate->hdr.buffer_len = sizeof(*deactivate);
+   deactivate->handle = handle;
+   ret = psp_guest_deactivate(deactivate, _ret);
+   if (ret) {
+   printk(KERN_ERR "SEV: DEACTIVATE ret=%d (%#010x)\n",
+   ret, psp_ret);
+   goto buffer_free;
+   }
+
+   wbinvd_on_all_cpus();
+
+   ret = psp_guest_df_flush(_ret);
+   if (ret)
+   printk(KERN_ERR "SEV: DF_FLUSH ret=%d (%#010x)\n",
+   ret, psp_ret);
+
+buffer_free:
+   kfree(deactivate);
+}
+
+static int sev_activate_asid(unsigned int handle, int asid, int *psp_ret)
+{
+   int ret;
+   struct psp_data_activate *activate;
+
+   wbinvd_on_all_cpus();
+
+   ret = psp_guest_df_flush(psp_ret);
+   if (ret) {
+   printk(KERN_ERR "SEV: DF_FLUSH ret=%d (%#010x)\n",
+   ret, *psp_ret);
+   return ret;
+   }
+
+   activate = kzalloc(sizeof(*activate), GFP_KERNEL);
+   if (!activate)
+   return -ENOMEM;
+
+   activate->hdr.buffer_len = sizeof(*activate);
+   activate->handle = handle;
+   activate->asid   = asid;
+   ret = psp_guest_activate(activate, psp_ret);
+   if (ret)
+   printk(KERN_ERR "SEV: ACTIVATE ret=%d (%#010x)\n",
+   ret, *psp_ret);
+   kfree(activate);
+   return ret;
+}
+
+static int sev_pre_start(struct kvm *kvm, int *asid)
+{
+   int ret;
+
+   /* If guest has active psp handle then deactivate before calling
+* launch start.
+*/
+   if (kvm_sev_guest()) {
+   sev_deactivate_handle(kvm_sev_handle());
+   sev_decommission_handle(kvm_sev_handle());
+   *asid = kvm->arch.sev_info.asid;  /* reuse the asid */
+   ret = 0;
+   } else {
+   /* Allocate new asid for this launch */
+   ret = sev_asid_new();
+   if (ret < 0) {
+   printk(KERN_ERR "SEV: failed to allocate asid\n");
+   return ret;
+   }
+   *asid = ret;
+   ret = 0;
+   }
+
+   return ret;
+}
+
+static int sev_post_start(struct kvm *kvm, int asid, int handle, int *psp_ret)
+{
+   int ret;
+
+   /* 

[RFC PATCH v1 18/28] crypto: add AMD Platform Security Processor driver

2016-08-22 Thread Brijesh Singh
The driver to communicate with Secure Encrypted Virtualization (SEV)
firmware running within the AMD secure processor providing a secure key
management interface for SEV guests.

Signed-off-by: Tom Lendacky 
Signed-off-by: Brijesh Singh 
---
 drivers/crypto/Kconfig   |   11 +
 drivers/crypto/Makefile  |1 
 drivers/crypto/psp/Kconfig   |8 
 drivers/crypto/psp/Makefile  |3 
 drivers/crypto/psp/psp-dev.c |  220 +++
 drivers/crypto/psp/psp-dev.h |   95 +
 drivers/crypto/psp/psp-ops.c |  454 +++
 drivers/crypto/psp/psp-pci.c |  376 +++
 include/linux/ccp-psp.h  |  833 ++
 include/uapi/linux/Kbuild|1 
 include/uapi/linux/ccp-psp.h |  182 +
 11 files changed, 2184 insertions(+)
 create mode 100644 drivers/crypto/psp/Kconfig
 create mode 100644 drivers/crypto/psp/Makefile
 create mode 100644 drivers/crypto/psp/psp-dev.c
 create mode 100644 drivers/crypto/psp/psp-dev.h
 create mode 100644 drivers/crypto/psp/psp-ops.c
 create mode 100644 drivers/crypto/psp/psp-pci.c
 create mode 100644 include/linux/ccp-psp.h
 create mode 100644 include/uapi/linux/ccp-psp.h

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 1af94e2..3bdbc51 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -464,6 +464,17 @@ if CRYPTO_DEV_CCP
source "drivers/crypto/ccp/Kconfig"
 endif
 
+config CRYPTO_DEV_PSP
+   bool "Support for AMD Platform Security Processor"
+   depends on X86 && PCI
+   help
+ The AMD Platform Security Processor provides hardware key-
+ management services for VMGuard encrypted memory.
+
+if CRYPTO_DEV_PSP
+   source "drivers/crypto/psp/Kconfig"
+endif
+
 config CRYPTO_DEV_MXS_DCP
tristate "Support for Freescale MXS DCP"
depends on (ARCH_MXS || ARCH_MXC)
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 3c6432d..1ea1e08 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_CRYPTO_DEV_ATMEL_SHA) += atmel-sha.o
 obj-$(CONFIG_CRYPTO_DEV_ATMEL_TDES) += atmel-tdes.o
 obj-$(CONFIG_CRYPTO_DEV_BFIN_CRC) += bfin_crc.o
 obj-$(CONFIG_CRYPTO_DEV_CCP) += ccp/
+obj-$(CONFIG_CRYPTO_DEV_PSP) += psp/
 obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM) += caam/
 obj-$(CONFIG_CRYPTO_DEV_GEODE) += geode-aes.o
 obj-$(CONFIG_CRYPTO_DEV_HIFN_795X) += hifn_795x.o
diff --git a/drivers/crypto/psp/Kconfig b/drivers/crypto/psp/Kconfig
new file mode 100644
index 000..acd9b87
--- /dev/null
+++ b/drivers/crypto/psp/Kconfig
@@ -0,0 +1,8 @@
+config CRYPTO_DEV_PSP_DD
+   tristate "PSP Key Management device driver"
+   depends on CRYPTO_DEV_PSP
+   default m
+   help
+ Provides the interface to use the AMD PSP key management APIs
+ for use with the AMD Secure Enhanced Virtualization. If you
+ choose 'M' here, this module will be called psp.
diff --git a/drivers/crypto/psp/Makefile b/drivers/crypto/psp/Makefile
new file mode 100644
index 000..1b7d00c
--- /dev/null
+++ b/drivers/crypto/psp/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_CRYPTO_DEV_PSP_DD) += psp.o
+psp-objs := psp-dev.o psp-ops.o
+psp-$(CONFIG_PCI) += psp-pci.o
diff --git a/drivers/crypto/psp/psp-dev.c b/drivers/crypto/psp/psp-dev.c
new file mode 100644
index 000..65d5c7e
--- /dev/null
+++ b/drivers/crypto/psp/psp-dev.c
@@ -0,0 +1,220 @@
+/*
+ * AMD Cryptographic Coprocessor (CCP) driver
+ *
+ * Copyright (C) 2016 Advanced Micro Devices, Inc.
+ *
+ * Author: Tom Lendacky 
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "psp-dev.h"
+
+MODULE_AUTHOR("Advanced Micro Devices, Inc.");
+MODULE_LICENSE("GPL");
+MODULE_VERSION("0.1.0");
+MODULE_DESCRIPTION("AMD VMGuard key-management driver prototype");
+
+static struct psp_device *psp_master;
+
+static LIST_HEAD(psp_devs);
+static DEFINE_SPINLOCK(psp_devs_lock);
+
+static atomic_t psp_id;
+
+static void psp_add_device(struct psp_device *psp)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(_devs_lock, flags);
+
+   list_add_tail(>entry, _devs);
+   psp_master = psp->get_master(_devs);
+
+   spin_unlock_irqrestore(_devs_lock, flags);
+}
+
+static void psp_del_device(struct psp_device *psp)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(_devs_lock, flags);
+
+   list_del(>entry);
+   if (psp == psp_master)
+   psp_master = NULL;
+
+   spin_unlock_irqrestore(_devs_lock, flags);
+}
+
+static void psp_check_support(struct psp_device *psp)
+{
+   if (ioread32(psp->io_regs + PSP_CMDRESP))
+   psp->sev_enabled = 1;
+}
+
+/**
+ * psp_get_master_device - returns a pointer to the 

[RFC PATCH v1 21/28] KVM: introduce KVM_SEV_ISSUE_CMD ioctl

2016-08-22 Thread Brijesh Singh
The ioctl will be used by qemu to issue the Secure Encrypted
Virtualization (SEV) guest commands to transition a guest into
into SEV-enabled mode.

a typical usage:

struct kvm_sev_launch_start start;
struct kvm_sev_issue_cmd data;

data.cmd = KVM_SEV_LAUNCH_START;
data.opaque = 

ret = ioctl(fd, KVM_SEV_ISSUE_CMD, );

On SEV command failure, data.ret_code will contain the firmware error code.

Signed-off-by: Brijesh Singh 
---
 arch/x86/include/asm/kvm_host.h |3 +
 arch/x86/kvm/x86.c  |   13 
 include/uapi/linux/kvm.h|  125 +++
 3 files changed, 141 insertions(+)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 9b885fc..a94e37d 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1040,6 +1040,9 @@ struct kvm_x86_ops {
void (*cancel_hv_timer)(struct kvm_vcpu *vcpu);
 
void (*setup_mce)(struct kvm_vcpu *vcpu);
+
+   int (*sev_issue_cmd)(struct kvm *kvm,
+struct kvm_sev_issue_cmd __user *argp);
 };
 
 struct kvm_arch_async_pf {
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index d6f2f4b..0c0adad 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3820,6 +3820,15 @@ split_irqchip_unlock:
return r;
 }
 
+static int kvm_vm_ioctl_sev_issue_cmd(struct kvm *kvm,
+ struct kvm_sev_issue_cmd __user *argp)
+{
+   if (kvm_x86_ops->sev_issue_cmd)
+   return kvm_x86_ops->sev_issue_cmd(kvm, argp);
+
+   return -ENOTTY;
+}
+
 long kvm_arch_vm_ioctl(struct file *filp,
   unsigned int ioctl, unsigned long arg)
 {
@@ -4085,6 +4094,10 @@ long kvm_arch_vm_ioctl(struct file *filp,
r = kvm_vm_ioctl_enable_cap(kvm, );
break;
}
+   case KVM_SEV_ISSUE_CMD: {
+   r = kvm_vm_ioctl_sev_issue_cmd(kvm, argp);
+   break;
+   }
default:
r = kvm_vm_ioctl_assigned_device(kvm, ioctl, arg);
}
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 300ef25..72c18c3 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1274,6 +1274,131 @@ struct kvm_s390_ucas_mapping {
 /* Available with KVM_CAP_X86_SMM */
 #define KVM_SMI   _IO(KVMIO,   0xb7)
 
+/* Secure Encrypted Virtualization mode */
+enum sev_cmd {
+   KVM_SEV_LAUNCH_START = 0,
+   KVM_SEV_LAUNCH_UPDATE,
+   KVM_SEV_LAUNCH_FINISH,
+   KVM_SEV_GUEST_STATUS,
+   KVM_SEV_DBG_DECRYPT,
+   KVM_SEV_DBG_ENCRYPT,
+   KVM_SEV_RECEIVE_START,
+   KVM_SEV_RECEIVE_UPDATE,
+   KVM_SEV_RECEIVE_FINISH,
+   KVM_SEV_SEND_START,
+   KVM_SEV_SEND_UPDATE,
+   KVM_SEV_SEND_FINISH,
+   KVM_SEV_API_VERSION,
+   KVM_SEV_NR_MAX,
+};
+
+struct kvm_sev_issue_cmd {
+   __u32 cmd;
+   __u64 opaque;
+   __u32 ret_code;
+};
+
+struct kvm_sev_launch_start {
+   __u32 handle;
+   __u32 flags;
+   __u32 policy;
+   __u8 nonce[16];
+   __u8 dh_pub_qx[32];
+   __u8 dh_pub_qy[32];
+};
+
+struct kvm_sev_launch_update {
+   __u64   address;
+   __u32   length;
+};
+
+struct kvm_sev_launch_finish {
+   __u32 vcpu_count;
+   __u32 vcpu_length;
+   __u64 vcpu_mask_addr;
+   __u32 vcpu_mask_length;
+   __u8  measurement[32];
+};
+
+struct kvm_sev_guest_status {
+   __u32 policy;
+   __u32 state;
+};
+
+struct kvm_sev_dbg_decrypt {
+   __u64 src_addr;
+   __u64 dst_addr;
+   __u32 length;
+};
+
+struct kvm_sev_dbg_encrypt {
+   __u64 src_addr;
+   __u64 dst_addr;
+   __u32 length;
+};
+
+struct kvm_sev_receive_start {
+   __u32 handle;
+   __u32 flags;
+   __u32 policy;
+   __u8 policy_meas[32];
+   __u8 wrapped_tek[24];
+   __u8 wrapped_tik[24];
+   __u8 ten[16];
+   __u8 dh_pub_qx[32];
+   __u8 dh_pub_qy[32];
+   __u8 nonce[16];
+};
+
+struct kvm_sev_receive_update {
+   __u8 iv[16];
+   __u64 address;
+   __u32 length;
+};
+
+struct kvm_sev_receive_finish {
+   __u8 measurement[32];
+};
+
+struct kvm_sev_send_start {
+   __u8 nonce[16];
+   __u32 policy;
+   __u8 policy_meas[32];
+   __u8 wrapped_tek[24];
+   __u8 wrapped_tik[24];
+   __u8 ten[16];
+   __u8 iv[16];
+   __u32 flags;
+   __u8 api_major;
+   __u8 api_minor;
+   __u32 serial;
+   __u8 dh_pub_qx[32];
+   __u8 dh_pub_qy[32];
+   __u8 pek_sig_r[32];
+   __u8 pek_sig_s[32];
+   __u8 cek_sig_r[32];
+   __u8 cek_sig_s[32];
+   __u8 cek_pub_qx[32];
+   __u8 cek_pub_qy[32];
+   __u8 ask_sig_r[32];
+   __u8 ask_sig_s[32];
+   __u32 ncerts;
+   __u32 cert_length;
+   __u64 certs_addr;
+};
+
+struct kvm_sev_send_update {
+   __u32 length;
+   __u64 src_addr;
+   __u64 dst_addr;
+};
+
+struct kvm_sev_send_finish {
+   

[RFC PATCH v1 17/28] KVM: SVM: Enable SEV by setting the SEV_ENABLE cpu feature

2016-08-22 Thread Brijesh Singh
From: Tom Lendacky 

Modify the SVM cpuid update function to indicate if Secure Encrypted
Virtualization (SEV) is active by setting the SEV KVM cpu features bit
if SEV is active.  SEV is active if Secure Memory Encryption is active
in the host and the SEV_ENABLE bit of the VMCB is set.

Signed-off-by: Tom Lendacky 
---
 arch/x86/kvm/cpuid.c |4 +++-
 arch/x86/kvm/svm.c   |   18 ++
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 3235e0f..d34faea 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -583,7 +583,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,
entry->edx = 0;
break;
case 0x8000:
-   entry->eax = min(entry->eax, 0x801a);
+   entry->eax = min(entry->eax, 0x801f);
break;
case 0x8001:
entry->edx &= kvm_cpuid_8000_0001_edx_x86_features;
@@ -616,6 +616,8 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,
break;
case 0x801d:
break;
+   case 0x801f:
+   break;
/*Add support for Centaur's CPUID instruction*/
case 0xC000:
/*Just support up to 0xC004 now*/
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 9b59260..211be94 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -43,6 +43,7 @@
 #include 
 
 #include 
+#include 
 #include "trace.h"
 
 #define __ex(x) __kvm_handle_fault_on_reboot(x)
@@ -4677,10 +4678,27 @@ static void svm_cpuid_update(struct kvm_vcpu *vcpu)
 {
struct vcpu_svm *svm = to_svm(vcpu);
struct kvm_cpuid_entry2 *entry;
+   struct vmcb_control_area *ca = >vmcb->control;
+   struct kvm_cpuid_entry2 *features, *sev_info;
 
/* Update nrips enabled cache */
svm->nrips_enabled = !!guest_cpuid_has_nrips(>vcpu);
 
+   /* Check for Secure Encrypted Virtualization support */
+   features = kvm_find_cpuid_entry(vcpu, KVM_CPUID_FEATURES, 0);
+   if (!features)
+   return;
+
+   sev_info = kvm_find_cpuid_entry(vcpu, 0x801f, 0);
+   if (!sev_info)
+   return;
+
+   if (ca->nested_ctl & SVM_NESTED_CTL_SEV_ENABLE) {
+   features->eax |= (1 << KVM_FEATURE_SEV);
+   cpuid(0x801f, _info->eax, _info->ebx,
+ _info->ecx, _info->edx);
+   }
+
if (!kvm_vcpu_apicv_active(vcpu))
return;
 

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


[RFC PATCH v1 15/28] x86: Unroll string I/O when SEV is active

2016-08-22 Thread Brijesh Singh
From: Tom Lendacky 

Secure Encrypted Virtualization (SEV) does not support string I/O, so
unroll the string I/O operation into a loop operating on one element at
a time.

Signed-off-by: Tom Lendacky 
---
 arch/x86/include/asm/io.h |   26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index de25aad..130b3e2 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -303,14 +303,32 @@ static inline unsigned type in##bwl##_p(int port) 
\
\
 static inline void outs##bwl(int port, const void *addr, unsigned long count) \
 {  \
-   asm volatile("rep; outs" #bwl   \
-: "+S"(addr), "+c"(count) : "d"(port));\
+   if (sev_active) {   \
+   unsigned type *value = (unsigned type *)addr;   \
+   while (count) { \
+   out##bwl(*value, port); \
+   value++;\
+   count--;\
+   }   \
+   } else {\
+   asm volatile("rep; outs" #bwl   \
+: "+S"(addr), "+c"(count) : "d"(port));\
+   }   \
 }  \
\
 static inline void ins##bwl(int port, void *addr, unsigned long count) \
 {  \
-   asm volatile("rep; ins" #bwl\
-: "+D"(addr), "+c"(count) : "d"(port));\
+   if (sev_active) {   \
+   unsigned type *value = (unsigned type *)addr;   \
+   while (count) { \
+   *value = in##bwl(port); \
+   value++;\
+   count--;\
+   }   \
+   } else {\
+   asm volatile("rep; ins" #bwl\
+: "+D"(addr), "+c"(count) : "d"(port));\
+   }   \
 }
 
 BUILDIO(b, b, char)

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


[RFC PATCH v1 07/28] x86: Do not encrypt memory areas if SEV is enabled

2016-08-22 Thread Brijesh Singh
From: Tom Lendacky 

When running under SEV, some memory areas that were originally not
encrypted under SME are already encrypted. In these situations do not
attempt to encrypt them.

Signed-off-by: Tom Lendacky 
---
 arch/x86/kernel/head64.c |4 ++--
 arch/x86/kernel/setup.c  |7 ---
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 358d7bc..4a15def 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -114,7 +114,7 @@ static void __init create_unencrypted_mapping(void 
*address, unsigned long size)
unsigned long physaddr = (unsigned long)address - __PAGE_OFFSET;
pmdval_t pmd_flags, pmd;
 
-   if (!sme_me_mask)
+   if (!sme_me_mask || sev_active)
return;
 
/* Clear the encryption mask from the early_pmd_flags */
@@ -165,7 +165,7 @@ static void __init __clear_mapping(unsigned long address)
 
 static void __init clear_mapping(void *address, unsigned long size)
 {
-   if (!sme_me_mask)
+   if (!sme_me_mask || sev_active)
return;
 
do {
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index cec8a63..9c10383 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -380,10 +380,11 @@ static void __init reserve_initrd(void)
 
/*
 * This memory is marked encrypted by the kernel but the ramdisk
-* was loaded in the clear by the bootloader, so make sure that
-* the ramdisk image is encrypted.
+* was loaded in the clear by the bootloader (unless SEV is active),
+* so make sure that the ramdisk image is encrypted.
 */
-   sme_early_mem_enc(ramdisk_image, ramdisk_end - ramdisk_image);
+   if (!sev_active)
+   sme_early_mem_enc(ramdisk_image, ramdisk_end - ramdisk_image);
 
initrd_start = 0;
 

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


[RFC PATCH v1 03/28] kvm: svm: Use the hardware provided GPA instead of page walk

2016-08-22 Thread Brijesh Singh
From: Tom Lendacky 

When a guest causes a NPF which requires emulation, KVM sometimes walks
the guest page tables to translate the GVA to a GPA. This is unnecessary
most of the time on AMD hardware since the hardware provides the GPA in
EXITINFO2.

The only exception cases involve string operations involving rep or
operations that use two memory locations. With rep, the GPA will only be
the value of the initial NPF and with dual memory locations we won't know
which memory address was translated into EXITINFO2.

Signed-off-by: Tom Lendacky 
---
 arch/x86/include/asm/kvm_emulate.h |3 +++
 arch/x86/include/asm/kvm_host.h|3 +++
 arch/x86/kvm/svm.c |2 ++
 arch/x86/kvm/x86.c |   17 -
 4 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/kvm_emulate.h 
b/arch/x86/include/asm/kvm_emulate.h
index e9cd7be..2d1ac09 100644
--- a/arch/x86/include/asm/kvm_emulate.h
+++ b/arch/x86/include/asm/kvm_emulate.h
@@ -344,6 +344,9 @@ struct x86_emulate_ctxt {
struct read_cache mem_read;
 };
 
+/* String operation identifier (matches the definition in emulate.c) */
+#define CTXT_STRING_OP (1 << 13)
+
 /* Repeat String Operation Prefix */
 #define REPE_PREFIX0xf3
 #define REPNE_PREFIX   0xf2
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index c38f878..b1dd673 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -667,6 +667,9 @@ struct kvm_vcpu_arch {
 
int pending_ioapic_eoi;
int pending_external_vector;
+
+   /* GPA available (AMD only) */
+   bool gpa_available;
 };
 
 struct kvm_lpage_info {
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index fd5a9a8..9b2de7c 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -4055,6 +4055,8 @@ static int handle_exit(struct kvm_vcpu *vcpu)
 
trace_kvm_exit(exit_code, vcpu, KVM_ISA_SVM);
 
+   vcpu->arch.gpa_available = (exit_code == SVM_EXIT_NPF);
+
if (!is_cr_intercept(svm, INTERCEPT_CR0_WRITE))
vcpu->arch.cr0 = svm->vmcb->save.cr0;
if (npt_enabled)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 78295b0..d6f2f4b 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4382,7 +4382,19 @@ static int vcpu_mmio_gva_to_gpa(struct kvm_vcpu *vcpu, 
unsigned long gva,
return 1;
}
 
-   *gpa = vcpu->arch.walk_mmu->gva_to_gpa(vcpu, gva, access, exception);
+   /*
+* If the exit was due to a NPF we may already have a GPA.
+* If the GPA is present, use it to avoid the GVA to GPA table
+* walk. Note, this cannot be used on string operations since
+* string operation using rep will only have the initial GPA
+* from when the NPF occurred.
+*/
+   if (vcpu->arch.gpa_available &&
+   !(vcpu->arch.emulate_ctxt.d & CTXT_STRING_OP))
+   *gpa = exception->address;
+   else
+   *gpa = vcpu->arch.walk_mmu->gva_to_gpa(vcpu, gva, access,
+  exception);
 
if (*gpa == UNMAPPED_GVA)
return -1;
@@ -5504,6 +5516,9 @@ int x86_emulate_instruction(struct kvm_vcpu *vcpu,
}
 
 restart:
+   /* Save the faulting GPA (cr2) in the address field */
+   ctxt->exception.address = cr2;
+
r = x86_emulate_insn(ctxt);
 
if (r == EMULATION_INTERCEPTED)

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


[RFC PATCH v1 00/28] x86: Secure Encrypted Virtualization (AMD)

2016-08-22 Thread Brijesh Singh
This RFC series provides support for AMD's new Secure Encrypted 
Virtualization (SEV) feature. This RFC is build upon Secure Memory 
Encryption (SME) RFC.

SEV is an extension to the AMD-V architecture which supports running 
multiple VMs under the control of a hypervisor. When enabled, SEV 
hardware tags all code and data with its VM ASID which indicates which 
VM the data originated from or is intended for. This tag is kept with 
the data at all times when inside the SOC, and prevents that data from 
being used by anyone other than the owner. While the tag protects VM 
data inside the SOC, AES with 128 bit encryption protects data outside 
the SOC. When data leaves or enters the SOC, it is encrypted/decrypted 
respectively by hardware with a key based on the associated tag.

SEV guest VMs have the concept of private and shared memory.  Private memory
is encrypted with the  guest-specific key, while shared memory may be encrypted
with hypervisor key.  Certain types of memory (namely instruction pages and
guest page tables) are always treated as private memory by the hardware.
For data memory, SEV guest VMs can choose which pages they would like to
be private. The choice is done using the standard CPU page tables using
the C-bit, and is fully controlled by the guest. Due to security reasons
all the DMA operations inside the  guest must be performed on shared pages
(C-bit clear).  Note that since C-bit is only controllable by the guest OS
when it is operating in 64-bit or 32-bit PAE mode, in all other modes the
SEV hardware forces the C-bit to a 1.

SEV is designed to protect guest VMs from a benign but vulnerable
(i.e. not fully malicious) hypervisor. In particular, it reduces the attack
surface of guest VMs and can prevent certain types of VM-escape bugs
(e.g. hypervisor read-anywhere) from being used to steal guest data.

The RFC series also includes a crypto driver (psp.ko) which communicates
with SEV firmware that runs within the AMD secure processor provides a
secure key management interfaces. The hypervisor uses this interface to 
enable SEV for secure guest and perform common hypervisor activities
such as launching, running, snapshotting , migrating and debugging a 
guest. A new ioctl (KVM_SEV_ISSUE_CMD) is introduced which will enable
Qemu to send commands to the SEV firmware during guest life cycle.

The RFC series also includes patches required in guest OS to enable SEV 
feature. A guest OS can check SEV support by calling KVM_FEATURE cpuid 
instruction.

The following links provide additional details:

AMD Memory Encryption whitepaper:
 
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf

AMD64 Architecture Programmer's Manual:
http://support.amd.com/TechDocs/24593.pdf
SME is section 7.10
SEV is section 15.34

Secure Encrypted Virutualization Key Management:
http://support.amd.com/TechDocs/55766_SEV-KM API_Spec.pdf

---

TODO:
- send qemu/seabios RFC's on respective mailing list
- integrate the psp driver with CCP driver (they share the PCI id's)
- add SEV guest migration command support
- add SEV snapshotting command support
- determine how to do ioremap of physical memory with mem encryption enabled
  (e.g acpi tables)
- determine how to share the guest memory with hypervisor for to support
  pvclock driver

Brijesh Singh (11):
  crypto: add AMD Platform Security Processor driver
  KVM: SVM: prepare to reserve asid for SEV guest
  KVM: SVM: prepare for SEV guest management API support
  KVM: introduce KVM_SEV_ISSUE_CMD ioctl
  KVM: SVM: add SEV launch start command
  KVM: SVM: add SEV launch update command
  KVM: SVM: add SEV_LAUNCH_FINISH command
  KVM: SVM: add KVM_SEV_GUEST_STATUS command
  KVM: SVM: add KVM_SEV_DEBUG_DECRYPT command
  KVM: SVM: add KVM_SEV_DEBUG_ENCRYPT command
  KVM: SVM: add command to query SEV API version

Tom Lendacky (17):
  kvm: svm: Add support for additional SVM NPF error codes
  kvm: svm: Add kvm_fast_pio_in support
  kvm: svm: Use the hardware provided GPA instead of page walk
  x86: Secure Encrypted Virtualization (SEV) support
  KVM: SVM: prepare for new bit definition in nested_ctl
  KVM: SVM: Add SEV feature definitions to KVM
  x86: Do not encrypt memory areas if SEV is enabled
  Access BOOT related data encrypted with SEV active
  x86/efi: Access EFI data as encrypted when SEV is active
  x86: Change early_ioremap to early_memremap for BOOT data
  x86: Don't decrypt trampoline area if SEV is active
  x86: DMA support for SEV memory encryption
  iommu/amd: AMD IOMMU support for SEV
  x86: Don't set the SME MSR bit when SEV is active
  x86: Unroll string I/O when SEV is active
  x86: Add support to determine if running with SEV enabled
  KVM: SVM: Enable SEV by setting the SEV_ENABLE cpu feature


 arch/x86/boot/compressed/Makefile  |2 
 

[RFC PATCH v1 02/28] kvm: svm: Add kvm_fast_pio_in support

2016-08-22 Thread Brijesh Singh
From: Tom Lendacky 

Update the I/O interception support to add the kvm_fast_pio_in function
to speed up the in instruction similar to the out instruction.

Signed-off-by: Tom Lendacky 
---
 arch/x86/include/asm/kvm_host.h |1 +
 arch/x86/kvm/svm.c  |5 +++--
 arch/x86/kvm/x86.c  |   43 +++
 3 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 3f05d36..c38f878 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1133,6 +1133,7 @@ int kvm_set_msr(struct kvm_vcpu *vcpu, struct msr_data 
*msr);
 struct x86_emulate_ctxt;
 
 int kvm_fast_pio_out(struct kvm_vcpu *vcpu, int size, unsigned short port);
+int kvm_fast_pio_in(struct kvm_vcpu *vcpu, int size, unsigned short port);
 void kvm_emulate_cpuid(struct kvm_vcpu *vcpu);
 int kvm_emulate_halt(struct kvm_vcpu *vcpu);
 int kvm_vcpu_halt(struct kvm_vcpu *vcpu);
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index d8b9c8c..fd5a9a8 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -2131,7 +2131,7 @@ static int io_interception(struct vcpu_svm *svm)
++svm->vcpu.stat.io_exits;
string = (io_info & SVM_IOIO_STR_MASK) != 0;
in = (io_info & SVM_IOIO_TYPE_MASK) != 0;
-   if (string || in)
+   if (string)
return emulate_instruction(vcpu, 0) == EMULATE_DONE;
 
port = io_info >> 16;
@@ -2139,7 +2139,8 @@ static int io_interception(struct vcpu_svm *svm)
svm->next_rip = svm->vmcb->control.exit_info_2;
skip_emulated_instruction(>vcpu);
 
-   return kvm_fast_pio_out(vcpu, size, port);
+   return in ? kvm_fast_pio_in(vcpu, size, port)
+ : kvm_fast_pio_out(vcpu, size, port);
 }
 
 static int nmi_interception(struct vcpu_svm *svm)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index d432894..78295b0 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5579,6 +5579,49 @@ int kvm_fast_pio_out(struct kvm_vcpu *vcpu, int size, 
unsigned short port)
 }
 EXPORT_SYMBOL_GPL(kvm_fast_pio_out);
 
+static int complete_fast_pio_in(struct kvm_vcpu *vcpu)
+{
+   unsigned long val;
+
+   /* We should only ever be called with arch.pio.count equal to 1 */
+   BUG_ON(vcpu->arch.pio.count != 1);
+
+   /* For size less than 4 we merge, else we zero extend */
+   val = (vcpu->arch.pio.size < 4) ? kvm_register_read(vcpu, VCPU_REGS_RAX)
+   : 0;
+
+   /*
+* Since vcpu->arch.pio.count == 1 let emulator_pio_in_emulated perform
+* the copy and tracing
+*/
+   emulator_pio_in_emulated(>arch.emulate_ctxt, vcpu->arch.pio.size,
+vcpu->arch.pio.port, , 1);
+   kvm_register_write(vcpu, VCPU_REGS_RAX, val);
+
+   return 1;
+}
+
+int kvm_fast_pio_in(struct kvm_vcpu *vcpu, int size, unsigned short port)
+{
+   unsigned long val;
+   int ret;
+
+   /* For size less than 4 we merge, else we zero extend */
+   val = (size < 4) ? kvm_register_read(vcpu, VCPU_REGS_RAX) : 0;
+
+   ret = emulator_pio_in_emulated(>arch.emulate_ctxt, size, port,
+  , 1);
+   if (ret) {
+   kvm_register_write(vcpu, VCPU_REGS_RAX, val);
+   return ret;
+   }
+
+   vcpu->arch.complete_userspace_io = complete_fast_pio_in;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(kvm_fast_pio_in);
+
 static int kvmclock_cpu_down_prep(unsigned int cpu)
 {
__this_cpu_write(cpu_tsc_khz, 0);

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


[RFC PATCH v1 00/28] x86: Secure Encrypted Virtualization (AMD)

2016-08-22 Thread Brijesh Singh
This RFC series provides support for AMD's new Secure Encrypted 
Virtualization (SEV) feature. This RFC is build upon Secure Memory 
Encryption (SME) RFC.

SEV is an extension to the AMD-V architecture which supports running 
multiple VMs under the control of a hypervisor. When enabled, SEV 
hardware tags all code and data with its VM ASID which indicates which 
VM the data originated from or is intended for. This tag is kept with 
the data at all times when inside the SOC, and prevents that data from 
being used by anyone other than the owner. While the tag protects VM 
data inside the SOC, AES with 128 bit encryption protects data outside 
the SOC. When data leaves or enters the SOC, it is encrypted/decrypted 
respectively by hardware with a key based on the associated tag.

SEV guest VMs have the concept of private and shared memory.  Private memory
is encrypted with the  guest-specific key, while shared memory may be encrypted
with hypervisor key.  Certain types of memory (namely instruction pages and
guest page tables) are always treated as private memory by the hardware.
For data memory, SEV guest VMs can choose which pages they would like to
be private. The choice is done using the standard CPU page tables using
the C-bit, and is fully controlled by the guest. Due to security reasons
all the DMA operations inside the  guest must be performed on shared pages
(C-bit clear).  Note that since C-bit is only controllable by the guest OS
when it is operating in 64-bit or 32-bit PAE mode, in all other modes the
SEV hardware forces the C-bit to a 1.

SEV is designed to protect guest VMs from a benign but vulnerable
(i.e. not fully malicious) hypervisor. In particular, it reduces the attack
surface of guest VMs and can prevent certain types of VM-escape bugs
(e.g. hypervisor read-anywhere) from being used to steal guest data.

The RFC series also includes a crypto driver (psp.ko) which communicates
with SEV firmware that runs within the AMD secure processor provides a
secure key management interfaces. The hypervisor uses this interface to 
enable SEV for secure guest and perform common hypervisor activities
such as launching, running, snapshotting , migrating and debugging a 
guest. A new ioctl (KVM_SEV_ISSUE_CMD) is introduced which will enable
Qemu to send commands to the SEV firmware during guest life cycle.

The RFC series also includes patches required in guest OS to enable SEV 
feature. A guest OS can check SEV support by calling KVM_FEATURE cpuid 
instruction.

The following links provide additional details:

AMD Memory Encryption whitepaper:
 
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf

AMD64 Architecture Programmer's Manual:
http://support.amd.com/TechDocs/24593.pdf
SME is section 7.10
SEV is section 15.34

Secure Encrypted Virutualization Key Management:
http://support.amd.com/TechDocs/55766_SEV-KM API_Spec.pdf

---

TODO:
- send qemu/seabios RFC's on respective mailing list
- integrate the psp driver with CCP driver (they share the PCI id's)
- add SEV guest migration command support
- add SEV snapshotting command support
- determine how to do ioremap of physical memory with mem encryption enabled
  (e.g acpi tables)
- determine how to share the guest memory with hypervisor for to support
  pvclock driver

Brijesh Singh (11):
  crypto: add AMD Platform Security Processor driver
  KVM: SVM: prepare to reserve asid for SEV guest
  KVM: SVM: prepare for SEV guest management API support
  KVM: introduce KVM_SEV_ISSUE_CMD ioctl
  KVM: SVM: add SEV launch start command
  KVM: SVM: add SEV launch update command
  KVM: SVM: add SEV_LAUNCH_FINISH command
  KVM: SVM: add KVM_SEV_GUEST_STATUS command
  KVM: SVM: add KVM_SEV_DEBUG_DECRYPT command
  KVM: SVM: add KVM_SEV_DEBUG_ENCRYPT command
  KVM: SVM: add command to query SEV API version

Tom Lendacky (17):
  kvm: svm: Add support for additional SVM NPF error codes
  kvm: svm: Add kvm_fast_pio_in support
  kvm: svm: Use the hardware provided GPA instead of page walk
  x86: Secure Encrypted Virtualization (SEV) support
  KVM: SVM: prepare for new bit definition in nested_ctl
  KVM: SVM: Add SEV feature definitions to KVM
  x86: Do not encrypt memory areas if SEV is enabled
  Access BOOT related data encrypted with SEV active
  x86/efi: Access EFI data as encrypted when SEV is active
  x86: Change early_ioremap to early_memremap for BOOT data
  x86: Don't decrypt trampoline area if SEV is active
  x86: DMA support for SEV memory encryption
  iommu/amd: AMD IOMMU support for SEV
  x86: Don't set the SME MSR bit when SEV is active
  x86: Unroll string I/O when SEV is active
  x86: Add support to determine if running with SEV enabled
  KVM: SVM: Enable SEV by setting the SEV_ENABLE cpu feature


 arch/x86/boot/compressed/Makefile  |2 
 

[RFC PATCH v1 28/28] KVM: SVM: add command to query SEV API version

2016-08-22 Thread Brijesh Singh
Signed-off-by: Brijesh Singh 
---
 arch/x86/kvm/svm.c |   23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 4af195d..88b8f89 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -5779,6 +5779,25 @@ err_1:
return ret;
 }
 
+static int sev_api_version(int *psp_ret)
+{
+   int ret;
+   struct psp_data_status *status;
+
+   status = kzalloc(sizeof(*status), GFP_KERNEL);
+   if (!status)
+   return -ENOMEM;
+
+   ret = psp_platform_status(status, psp_ret);
+   if (ret)
+   goto err;
+
+   ret = (status->api_major << 8) | status->api_minor;
+err:
+   kfree(status);
+   return ret;
+}
+
 static int amd_sev_issue_cmd(struct kvm *kvm,
 struct kvm_sev_issue_cmd __user *user_data)
 {
@@ -5819,6 +5838,10 @@ static int amd_sev_issue_cmd(struct kvm *kvm,
_code);
break;
}
+   case KVM_SEV_API_VERSION: {
+   r = sev_api_version(_code);
+   break;
+   }
default:
break;
}

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


[RFC PATCH v1 24/28] KVM: SVM: add SEV_LAUNCH_FINISH command

2016-08-22 Thread Brijesh Singh
The command is used for finializing the guest launch into SEV mode.

For more information see [1], section 6.3

[1] http://support.amd.com/TechDocs/55766_SEV-KM%20API_Spec.pdf

Signed-off-by: Brijesh Singh 
---
 arch/x86/kvm/svm.c |   78 
 1 file changed, 78 insertions(+)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index c78bdc6..60cc0f7 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -5497,6 +5497,79 @@ err_1:
return ret;
 }
  
+static int sev_launch_finish(struct kvm *kvm,
+struct kvm_sev_launch_finish __user *argp,
+int *psp_ret)
+{
+   int i, ret;
+   void *mask = NULL;
+   int buffer_len, len;
+   struct kvm_vcpu *vcpu;
+   struct psp_data_launch_finish *finish;
+   struct kvm_sev_launch_finish params;
+
+   if (!kvm_sev_guest())
+   return -EINVAL;
+
+   /* Get the parameters from the user */
+   if (copy_from_user(, argp, sizeof(*argp)))
+   return -EFAULT;
+
+   buffer_len = sizeof(*finish) + (sizeof(u64) * params.vcpu_count);
+   finish = kzalloc(buffer_len, GFP_KERNEL);
+   if (!finish)
+   return -ENOMEM;
+
+   /* copy the vcpu mask from user */
+   if (params.vcpu_mask_length && params.vcpu_mask_addr) {
+   ret = -ENOMEM;
+   mask = (void *) get_zeroed_page(GFP_KERNEL);
+   if (!mask)
+   goto err_1;
+
+   len = min_t(size_t, PAGE_SIZE, params.vcpu_mask_length);
+   ret = -EFAULT;
+   if (copy_from_user(mask, (uint8_t*)params.vcpu_mask_addr, len))
+   goto err_2;
+   finish->vcpus.state_mask_addr = __psp_pa(mask);
+   }
+
+   finish->handle = kvm_sev_handle();
+   finish->hdr.buffer_len = buffer_len;
+   finish->vcpus.state_count = params.vcpu_count;
+   finish->vcpus.state_length = params.vcpu_length;
+   kvm_for_each_vcpu(i, vcpu, kvm) {
+   finish->vcpus.state_addr[i] =
+   to_svm(vcpu)->vmcb_pa | sme_me_mask;
+   if (i == params.vcpu_count)
+   break;
+   }
+
+   /* launch finish */
+   ret = psp_guest_launch_finish(finish, psp_ret);
+   if (ret) {
+   printk(KERN_ERR "SEV: LAUNCH_FINISH ret=%d (%#010x)\n",
+   ret, *psp_ret);
+   goto err_2;
+   }
+
+   /* Iterate through each vcpus and set SEV KVM_SEV_FEATURE bit in
+* KVM_CPUID_FEATURE to indicate that SEV is enabled on this vcpu
+*/
+   kvm_for_each_vcpu(i, vcpu, kvm)
+   svm_cpuid_update(vcpu);
+
+   /* copy the measurement for user */
+   if (copy_to_user(argp->measurement, finish->measurement, 32))
+   ret = -EFAULT;
+
+err_2:
+   free_page((unsigned long)mask);
+err_1:
+   kfree(finish);
+   return ret;
+}
+
 static int amd_sev_issue_cmd(struct kvm *kvm,
 struct kvm_sev_issue_cmd __user *user_data)
 {
@@ -5517,6 +5590,11 @@ static int amd_sev_issue_cmd(struct kvm *kvm,
_code);
break;
}
+   case KVM_SEV_LAUNCH_FINISH: {
+   r = sev_launch_finish(kvm, (void *)arg.opaque,
+   _code);
+   break;
+   }
default:
break;
}

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


[RFC PATCH v1 25/28] KVM: SVM: add KVM_SEV_GUEST_STATUS command

2016-08-22 Thread Brijesh Singh
The command is used to query the SEV guest status.

For more information see [1], section 6.10

[1] http://support.amd.com/TechDocs/55766_SEV-KM%20API_Spec.pdf

Signed-off-by: Brijesh Singh 
---
 arch/x86/kvm/svm.c |   41 +
 1 file changed, 41 insertions(+)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 60cc0f7..63e7d15 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -5570,6 +5570,42 @@ err_1:
return ret;
 }
 
+static int sev_guest_status(struct kvm *kvm,
+   struct kvm_sev_guest_status __user *argp,
+   int *psp_ret)
+{
+   int ret;
+   struct kvm_sev_guest_status params;
+   struct psp_data_guest_status *status;
+
+   if (!kvm_sev_guest())
+   return -ENOTTY;
+
+   if (copy_from_user(, argp, sizeof(*argp)))
+   return -EFAULT;
+
+   status = kzalloc(sizeof(*status), GFP_KERNEL);
+   if (!status)
+   return -ENOMEM;
+
+   status->hdr.buffer_len = sizeof(*status);
+   status->handle = kvm_sev_handle();
+   ret = psp_guest_status(status, psp_ret);
+   if (ret) {
+   printk(KERN_ERR "SEV: GUEST_STATUS ret=%d (%#010x)\n",
+   ret, *psp_ret);
+   goto err_1;
+   }
+   params.policy = status->policy;
+   params.state = status->state;
+
+   if (copy_to_user(argp, , sizeof(*argp)))
+   ret = -EFAULT;
+err_1:
+   kfree(status);
+   return ret;
+}
+
 static int amd_sev_issue_cmd(struct kvm *kvm,
 struct kvm_sev_issue_cmd __user *user_data)
 {
@@ -5595,6 +5631,11 @@ static int amd_sev_issue_cmd(struct kvm *kvm,
_code);
break;
}
+   case KVM_SEV_GUEST_STATUS: {
+   r = sev_guest_status(kvm, (void *)arg.opaque,
+   _code);
+   break;
+   }
default:
break;
}

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


Re: [PATCH 0/2] staging: vt6655: fix checkpatch warning for trailing */ on a separate line

2016-08-22 Thread Anson Jacob
On Mon, Aug 22, 2016 at 04:36:26PM -0400, Greg Kroah-Hartman wrote:
> On Mon, Aug 22, 2016 at 12:54:12PM -0400, Anson Jacob wrote:
> > *** BLURB HERE ***
> 
> You forgot the blurb :)
> 
Sorry about that. Uploaded a new patchset with blurb :)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v2 2/2] staging: vt6655: rxtx.c: Fix checkpatch warning

2016-08-22 Thread Anson Jacob
Fix checkpatch.pl warning for trailing */ on a separate line
Remove '+' postfix and '-' prefix from the start and end of block comments

Signed-off-by: Anson Jacob 
---
 drivers/staging/vt6655/rxtx.c | 41 -
 1 file changed, 24 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/vt6655/rxtx.c b/drivers/staging/vt6655/rxtx.c
index e4c3165..890d108 100644
--- a/drivers/staging/vt6655/rxtx.c
+++ b/drivers/staging/vt6655/rxtx.c
@@ -64,8 +64,10 @@
 /*-  Static Functions  --*/
 
 /*-  Static Definitions -*/
-#define CRITICAL_PACKET_LEN  256/* if packet size < 256 -> in-direct 
send
-packet size >= 256 -> direct send 
*/
+/* if packet size < 256 -> in-direct send
+ * vpacket size >= 256 -> direct send
+ */
+#define CRITICAL_PACKET_LEN  256
 
 static const unsigned short wTimeStampOff[2][MAX_RATE] = {
{384, 288, 226, 209, 54, 43, 37, 31, 28, 25, 24, 23}, /* Long Preamble 
*/
@@ -158,11 +160,11 @@ static __le16 vnt_time_stamp_off(struct vnt_private 
*priv, u16 rate)
[rate % MAX_RATE]);
 }
 
-/*byPktType : PK_TYPE_11A 0
-  PK_TYPE_11B 1
-  PK_TYPE_11GB2
-  PK_TYPE_11GA3
-*/
+/* byPktType : PK_TYPE_11A 0
+ * PK_TYPE_11B 1
+ * PK_TYPE_11GB2
+ * PK_TYPE_11GA3
+ */
 static
 unsigned int
 s_uGetTxRsvTime(
@@ -650,13 +652,16 @@ s_vFillRTSHead(
return;
 
if (bDisCRC) {
-   /* When CRCDIS bit is on, H/W forgot to generate FCS for RTS 
frame,
-in this case we need to decrease its length by 4. */
+   /* When CRCDIS bit is on, H/W forgot to generate FCS for
+* RTS frame, in this case we need to decrease its length by 4.
+*/
uRTSFrameLen -= 4;
}
 
-   /* Note: So far RTSHead doesn't appear in ATIM & Beacom DMA, so we 
don't need to take them into account.
-  Otherwise, we need to modify codes for them. */
+   /* Note: So far RTSHead doesn't appear in ATIM & Beacom DMA,
+* so we don't need to take them into account.
+* Otherwise, we need to modify codes for them.
+*/
if (byPktType == PK_TYPE_11GB || byPktType == PK_TYPE_11GA) {
if (byFBOption == AUTO_FB_NONE) {
struct vnt_rts_g *buf = pvRTS;
@@ -842,8 +847,9 @@ s_vFillCTSHead(
return;
 
if (bDisCRC) {
-   /* When CRCDIS bit is on, H/W forgot to generate FCS for CTS 
frame,
-in this case we need to decrease its length by 4. */
+   /* When CRCDIS bit is on, H/W forgot to generate FCS for
+* CTS frame, in this case we need to decrease its length by 4.
+*/
uCTSFrameLen -= 4;
}
 
@@ -915,7 +921,7 @@ s_vFillCTSHead(
}
 }
 
-/*+
+/*
  *
  * Description:
  *  Generate FIFO control for MAC & Baseband controller
@@ -937,7 +943,8 @@ s_vFillCTSHead(
  * Return Value: none
  *
  -
- * unsigned int cbFrameSize, Hdr+Payload+FCS */
+ * unsigned int cbFrameSize, Hdr+Payload+FCS
+ */
 static
 void
 s_vGenerateTxParameter(
@@ -972,8 +979,8 @@ s_vGenerateTxParameter(
return;
 
if (byPktType == PK_TYPE_11GB || byPktType == PK_TYPE_11GA) {
-   if (pvRTS != NULL) { /* RTS_need
-Fill RsvTime */
+   if (pvRTS != NULL) { /* RTS_need */
+   /* Fill RsvTime */
struct vnt_rrv_time_rts *buf = pvRrvTime;
 
buf->rts_rrv_time_aa = s_uGetRTSCTSRsvTime(pDevice, 2, 
byPktType, cbFrameSize, wCurrentRate);
-- 
2.7.4

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


[PATCH v2 1/2] staging: vt6655: rf.c: Fix checkpatch warning

2016-08-22 Thread Anson Jacob
Fix checkpatch.pl warning for trailing */ on a separate line
Remove '+' postfix and '-' prefix from the start and end of block comments

Signed-off-by: Anson Jacob 
---
 drivers/staging/vt6655/rf.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/vt6655/rf.c b/drivers/staging/vt6655/rf.c
index ae10da2..447882c 100644
--- a/drivers/staging/vt6655/rf.c
+++ b/drivers/staging/vt6655/rf.c
@@ -169,7 +169,8 @@ static unsigned long dwAL2230PowerTable[AL2230_PWR_IDX_LEN] 
= {
 };
 
 /* 40MHz reference frequency
- * Need to Pull PLLON(PE3) low when writing channel registers through 3-wire.*/
+ * Need to Pull PLLON(PE3) low when writing channel registers through 3-wire.
+ */
 static const unsigned long dwAL7230InitTable[CB_AL7230_INIT_SEQ] = {
0x00379000+(BY_AL7230_REG_LEN<<3)+IFREGCTL_REGW, /* Channel1 // Need 
modify for 11a */
0x1100+(BY_AL7230_REG_LEN<<3)+IFREGCTL_REGW, /* Channel1 // Need 
modify for 11a */
@@ -463,7 +464,8 @@ static bool s_bAL7230Init(struct vnt_private *priv)
 }
 
 /* Need to Pull PLLON low when writing channel registers through
- * 3-wire interface */
+ * 3-wire interface
+ */
 static bool s_bAL7230SelectChannel(struct vnt_private *priv, unsigned char 
byChannel)
 {
void __iomem *dwIoBase = priv->PortOffset;
@@ -873,7 +875,8 @@ bool RFbRawSetPower(
 
case RF_AIROHA7230:
/* 0x080F1B00 for 3 wire control TxGain(D10)
-* and 0x31 as TX Gain value */
+* and 0x31 as TX Gain value
+*/
dwMax7230Pwr = 0x080C0B00 | ((byPwr) << 12) |
(BY_AL7230_REG_LEN << 3)  | IFREGCTL_REGW;
 
@@ -886,7 +889,7 @@ bool RFbRawSetPower(
return ret;
 }
 
-/*+
+/*
  *
  * Routine Description:
  * Translate RSSI to dBm
@@ -900,7 +903,7 @@ bool RFbRawSetPower(
  *
  * Return Value: none
  *
- -*/
+ */
 void
 RFvRSSITodBm(
struct vnt_private *priv,
@@ -927,7 +930,8 @@ RFvRSSITodBm(
 }
 
 /* Post processing for the 11b/g and 11a.
- * for save time on changing Reg2,3,5,7,10,12,15 */
+ * for save time on changing Reg2,3,5,7,10,12,15
+ */
 bool RFbAL7230SelectChannelPostProcess(struct vnt_private *priv,
   u16 byOldChannel,
   u16 byNewChannel)
@@ -938,7 +942,8 @@ bool RFbAL7230SelectChannelPostProcess(struct vnt_private 
*priv,
 
/* if change between 11 b/g and 11a need to update the following
 * register
-* Channel Index 1~14 */
+* Channel Index 1~14
+*/
if ((byOldChannel <= CB_MAX_CHANNEL_24G) && (byNewChannel > 
CB_MAX_CHANNEL_24G)) {
/* Change from 2.4G to 5G [Reg] */
ret &= IFRFbWriteEmbedded(priv, dwAL7230InitTableAMode[2]);
-- 
2.7.4

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


[PATCH v2 0/2] staging: vt6655: fix checkpatch warning for trailing */ on a separate line

2016-08-22 Thread Anson Jacob
Fix checkpatch.pl warning for trailing */ on a separate line
Remove '+' postfix and '-' prefix from the start and end of block comments

Anson Jacob (2):
  staging: vt6655: rf.c: Fix checkpatch warning
  staging: vt6655: rxtx.c: Fix checkpatch warning

 drivers/staging/vt6655/rf.c   | 19 ---
 drivers/staging/vt6655/rxtx.c | 41 -
 2 files changed, 36 insertions(+), 24 deletions(-)

-- 
2.7.4

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


Re: [staging:staging-testing 201/347] drivers/staging/lustre/lustre/mdc/mdc_request.c:1243:32: error: 'dp' undeclared

2016-08-22 Thread Greg Kroah-Hartman
On Mon, Aug 22, 2016 at 05:48:39PM +0100, James Simmons wrote:
> 
> > On Mon, Aug 22, 2016 at 03:15:23PM +0800, kbuild test robot wrote:
> > > tree:   
> > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
> > > staging-testing
> > > head:   f5a9a15f8fd4168e415e94f5dce367f3cef08e03
> > > commit: 4f76f0ec093c2f9ef049495c78d486bfb48e4de0 [201/347] staging: 
> > > lustre: llite: move dir cache to MDC layer
> > > config: alpha-allyesconfig (attached as .config)
> > > compiler: alpha-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
> > > reproduce:
> > > wget 
> > > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> > >  -O ~/bin/make.cross
> > > chmod +x ~/bin/make.cross
> > > git checkout 4f76f0ec093c2f9ef049495c78d486bfb48e4de0
> > > # save the attached .config to linux build tree
> > > make.cross ARCH=alpha 
> > 
> > Odd, I can't duplicate this on x86, what's so strange about alpha?
> 
> I see what the problem is. Its one of those 64K page versus 4K page 
> issues. I will send a patch right away.

Thanks, now queued up.

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


Re: [PATCH 0/7] staging: lustre: last missing patches for lustre 2.6

2016-08-22 Thread Greg Kroah-Hartman
On Mon, Aug 22, 2016 at 10:55:42AM -0700, Joe Perches wrote:
> On Mon, 2016-08-22 at 18:41 +0100, James Simmons wrote:
> > On Fri, 2016-08-19 at 20:44 +0100, James Simmons wrote:
> 
> Hi again James.
> 
> > > I don't _need_ anything, but I think it'd be simpler to
> > > have just 2 directories, one for lustre kernel stuff
> > > and another for lustre uapi stuff.
> > > 
> > > That applies for LNet and libcfs #includes as well.
> > > 
> > > To me, ideally, there'd only be 2 #include directories
> > > so that the only used #include styles could become:
> > > 
> > > #include 
> > > and
> > > #include 
> > > 
> > > and that would work regardless of lustre's layout
> > > in staging or elsewhere.
> > I didn't expect this to be requested at this time. I thought this would be 
> > addressed just before we left staging.
> 
> Sooner is better to me, but that's up to you all.

No, please, let's wait, there's still lots of "real" work to be done in
the lustre code before messing with the .h files like this.

James, please just continue the great work you are doing so far, all is
fine :)

thanks,

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


Re: [PATCH 0/2] staging: vt6655: fix checkpatch warning for trailing */ on a separate line

2016-08-22 Thread Greg Kroah-Hartman
On Mon, Aug 22, 2016 at 12:54:12PM -0400, Anson Jacob wrote:
> *** BLURB HERE ***

You forgot the blurb :)

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


Re: [PATCH -next] PCI: hv: Use list_move_tail instead of list_del/list_add_tail

2016-08-22 Thread Bjorn Helgaas
On Thu, Jul 28, 2016 at 04:16:48PM +, Wei Yongjun wrote:
> Using list_move_tail() instead of list_del() + list_add_tail().
> 
> Signed-off-by: Wei Yongjun 

Applied to pci/host-hv for v4.9, thanks!

> ---
>  drivers/pci/host/pci-hyperv.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
> index 6955ffdb..a8deeca 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -1466,8 +1466,7 @@ static void pci_devices_present_work(struct work_struct 
> *work)
>   if (hpdev->reported_missing) {
>   found = true;
>   put_pcichild(hpdev, hv_pcidev_ref_childlist);
> - list_del(>list_entry);
> - list_add_tail(>list_entry, );
> + list_move_tail(>list_entry, );
>   break;
>   }
>   }
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH V2] rtlwifi: Fix missing country code for Great Britain

2016-08-22 Thread Larry Finger
Some RTL8821AE devices sold in Great Britain have the country code of
0x25 encoded in their EEPROM. This value is not tested in the routine
that establishes the regulatory info for the chip. The fix is to set
this code to have the same capabilities as the EU countries. In addition,
the channels allowed for COUNTRY_CODE_ETSI were more properly suited
for China and Israel, not the EU. This problem has also been fixed.

Signed-off-by: Larry Finger 
Cc: Stable 
---

V2 - Explain why channels for ETSI have been modified.
---
 drivers/net/wireless/realtek/rtlwifi/regd.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/regd.c 
b/drivers/net/wireless/realtek/rtlwifi/regd.c
index 3524441..6ee6bf8 100644
--- a/drivers/net/wireless/realtek/rtlwifi/regd.c
+++ b/drivers/net/wireless/realtek/rtlwifi/regd.c
@@ -345,9 +345,9 @@ static const struct ieee80211_regdomain 
*_rtl_regdomain_select(
return _regdom_no_midband;
case COUNTRY_CODE_IC:
return _regdom_11;
-   case COUNTRY_CODE_ETSI:
case COUNTRY_CODE_TELEC_NETGEAR:
return _regdom_60_64;
+   case COUNTRY_CODE_ETSI:
case COUNTRY_CODE_SPAIN:
case COUNTRY_CODE_FRANCE:
case COUNTRY_CODE_ISRAEL:
@@ -406,6 +406,8 @@ static u8 channel_plan_to_country_code(u8 channelplan)
return COUNTRY_CODE_WORLD_WIDE_13;
case 0x22:
return COUNTRY_CODE_IC;
+   case 0x25:
+   return COUNTRY_CODE_ETSI;
case 0x32:
return COUNTRY_CODE_TELEC_NETGEAR;
case 0x41:
-- 
2.6.6

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


Re: [PATCH] rtlwifi: Fix missing country code for Great Britain

2016-08-22 Thread Larry Finger

On 08/22/2016 10:36 AM, Kalle Valo wrote:

Larry Finger  writes:


Some RTL8821AE devices sold in Great Britain have the country code of
0x25 encoded in their EEPROM. This value is not tested in the routine
that establishes the regulatory info for the chip. The fix is to set
this code to have the same capabilities as the EU countries.

Signed-off-by: Larry Finger 
Cc: Stable 


[...]


--- a/drivers/net/wireless/realtek/rtlwifi/regd.c
+++ b/drivers/net/wireless/realtek/rtlwifi/regd.c
@@ -345,9 +345,9 @@ static const struct ieee80211_regdomain 
*_rtl_regdomain_select(
return _regdom_no_midband;
case COUNTRY_CODE_IC:
return _regdom_11;
-   case COUNTRY_CODE_ETSI:
case COUNTRY_CODE_TELEC_NETGEAR:
return _regdom_60_64;
+   case COUNTRY_CODE_ETSI:
case COUNTRY_CODE_SPAIN:
case COUNTRY_CODE_FRANCE:
case COUNTRY_CODE_ISRAEL:


I didn't check the full source, but here you seem to be changing also
the content of ETSI regdomain. The commit log doesn't mention anything
about that so I want to double check that this is really intentionally.


Yes, I did intend to change all of ETSI. It was previously allowing channels 
appropriate for China and Israel.


I will resubmit with an improved commit message.

Thanks,

Larry


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


[PATCH] Staging: comedi: fix spelling mistake "Firmare" -> "Firmware"

2016-08-22 Thread Colin King
From: Colin Ian King 

Trivial fix to spelling mistake in dev_dbg message.

Signed-off-by: Colin Ian King 
---
 drivers/staging/comedi/drivers/jr3_pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/jr3_pci.c 
b/drivers/staging/comedi/drivers/jr3_pci.c
index 6c4ff02..b9b686e 100644
--- a/drivers/staging/comedi/drivers/jr3_pci.c
+++ b/drivers/staging/comedi/drivers/jr3_pci.c
@@ -739,7 +739,7 @@ static int jr3_pci_auto_attach(struct comedi_device *dev,
ret = comedi_load_firmware(dev, _to_pci_dev(dev)->dev,
   "comedi/jr3pci.idm",
   jr3_download_firmware, 0);
-   dev_dbg(dev->class_dev, "Firmare load %d\n", ret);
+   dev_dbg(dev->class_dev, "Firmware load %d\n", ret);
if (ret < 0)
return ret;
/*
-- 
2.9.3

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


Re: [PATCH 0/7] staging: lustre: last missing patches for lustre 2.6

2016-08-22 Thread Joe Perches
On Mon, 2016-08-22 at 18:41 +0100, James Simmons wrote:
> On Fri, 2016-08-19 at 20:44 +0100, James Simmons wrote:

Hi again James.

> > I don't _need_ anything, but I think it'd be simpler to
> > have just 2 directories, one for lustre kernel stuff
> > and another for lustre uapi stuff.
> > 
> > That applies for LNet and libcfs #includes as well.
> > 
> > To me, ideally, there'd only be 2 #include directories
> > so that the only used #include styles could become:
> > 
> > #include 
> > and
> > #include 
> > 
> > and that would work regardless of lustre's layout
> > in staging or elsewhere.
> I didn't expect this to be requested at this time. I thought this would be 
> addressed just before we left staging.

Sooner is better to me, but that's up to you all.

> I had to ponder the impact of
> this change since this affects our userland utilities as well. Moving
> the staging/lustre/lustre/include/* to include/linux/lustre is pretty
> straight forward for the internal kernel headers.
> 
> The issues is that we still have entanglement issues with some of our uapi 
> headers with internals of the kernel leaking to userland.

Identifying the u_int_ and __u types in the code
by userland/kernel uses could be done more easily after any
#include uapi/kernel separation is done.
> Would that be acceptable?

That's not for me to decide really.
It's not an immediate or even necessary want.
It's just a code reading convenience to me.


> This Wednsday we have a lustre community conference call were we discuss
> upstream issues. This will need to be discussed.  

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


Re: [PATCH 0/7] staging: lustre: last missing patches for lustre 2.6

2016-08-22 Thread James Simmons

> On Fri, 2016-08-19 at 20:44 +0100, James Simmons wrote:
> > > 1: I'd like to see the lustre #include files separated into
> > >    only two internal/external directories akin to the
> > >    include/linux and include/uapi directories used by linux.
> []
> > For the first question yes it is reasonable and developers
> > have been working to cleanup and separate out the uapi headers
> > from the normal kernel headers. For staging/lustre/lustre we
> > have local headers *_internal.h which only matter for that
> > particular subdirectory. The rest of the headers are all in
> > 
> > staging/lustre/lustre/include/*
> > 
> > In that directory we have the linux subdirectory. That has
> > gone away in newer lustre versions so I would need to push
> > the patch to remove it. The other directory
> > 
> > staging/lustre/lustre/include/lustre/*
> > 
> > contains all our uapi headers like lustre_user.h and lustre_idl.h.
> > Well that is not entirely correct. We still have uapi headers
> > like uapi_kernelcomm.h one directory up. It just if we change those
> > I need to update our userland tools as well. I have a patch ready
> > but I need to push it to our utility branch as well.
> > The next lot is all the LNet/libcfs stuff. The good news for LNet
> > the headers have been cleaned up so separating them out is easy.
> > Well there can always be more improvements. Now libcfs is a bit
> > messy. The libcfs/linux directory needs to be removed yet. Also
> > libcfs_debug.h needs to broken up for uapi use.
> > 
> > Thats the run down about where we are at for the headers. Also it
> > gives you an idea where we are heading. So how do you need this
> > layed out for what you want to do? Where do you want to place the
> > headers?
> 
> Thanks.
> 
> I don't _need_ anything, but I think it'd be simpler to
> have just 2 directories, one for lustre kernel stuff
> and another for lustre uapi stuff.
> 
> That applies for LNet and libcfs #includes as well.
> 
> To me, ideally, there'd only be 2 #include directories
> so that the only used #include styles could become:
> 
> #include 
> and
> #include 
> 
> and that would work regardless of lustre's layout
> in staging or elsewhere.

I didn't expect this to be requested at this time. I thought this would be 
addressed just before we left staging. I had to ponder the impact of
this change since this affects our userland utilities as well. Moving
the staging/lustre/lustre/include/* to include/linux/lustre is pretty
straight forward for the internal kernel headers.

The issues is that we still have entanglement issues with some of our uapi 
headers with internals of the kernel leaking to userland. I can push the 
cleanups we have so far but its not complete. Its close but not yet 
their. The other issue is I see some of our uapi headers for the upstream
client got nuked i.e userland  ifdefs got remove, so they are useless for 
userland now. Besides that is the impact on our userland utilities. 
Currently we expect our lustre uapi headers to be in /usr/include/lustre.
I noticed for uapi headers their is a mapping of

include/uapi/XXX -> /usr/include/XXX

This would mean that instead of the lustre api being moved to 

include/uapi/linux/lustre 

they would need to be instead in

include/uapi/lustre

Would that be acceptable? If not I guess we could add userland wrappers in 
/usr/include/lustre that point to the uapi headers. In any case we have to 
figure out something for our utilities. The same goes for LNet. We tend to 
use /usr/include/lnet/XXX. Is inclue/uapi/lnet acceptable. Also the few 
libcfs headers we use in userland needs to find a new home. 

This Wednsday we have a lustre community conference call were we discuss
upstream issues. This will need to be discussed.  ___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: rts5208: rtsx.c: Fix checkpatch warnings.

2016-08-22 Thread Sudip Mukherjee
On Tue, Aug 23, 2016 at 12:54:17AM +0800, MingChia Chung wrote:
>   This patch fixes a minor checkpatch warnings:
> 
>   "WARNING: Block comments use a trailing */ on a separate line"
> 
>   Signed-off-by: Ming-Chia Chung 
> ---
>  drivers/staging/rts5208/rtsx.c | 42 
> --
>  1 file changed, 28 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/staging/rts5208/rtsx.c b/drivers/staging/rts5208/rtsx.c
> index e992e03..a880411 100644
> --- a/drivers/staging/rts5208/rtsx.c
> +++ b/drivers/staging/rts5208/rtsx.c
> @@ -81,14 +81,16 @@ static int slave_alloc(struct scsi_device *sdev)
>  
>  static int slave_configure(struct scsi_device *sdev)
>  {
> - /* Scatter-gather buffers (all but the last) must have a length
> + /*
> +   * Scatter-gather buffers (all but the last) must have a length

The alignment doesnot look correct here. Also in some more places later
in this patch.

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


[PATCH] staging: vt6656: usbpipe.c: Fix checkpatch warning

2016-08-22 Thread Anson Jacob
Fix checkpatch.pl warning for line over 80 characters

Signed-off-by: Anson Jacob 
---
 drivers/staging/vt6656/usbpipe.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/vt6656/usbpipe.c b/drivers/staging/vt6656/usbpipe.c
index f546553..e9b6b21 100644
--- a/drivers/staging/vt6656/usbpipe.c
+++ b/drivers/staging/vt6656/usbpipe.c
@@ -28,8 +28,9 @@
  * vnt_control_in_u8 - Read one byte from MEM/BB/MAC/EEPROM
  *
  * Revision History:
- *  04-05-2004 Jerry Chen:  Initial release
- *  11-24-2004 Warren Hsu: Add 
ControlvWriteByte,ControlvReadByte,ControlvMaskByte
+ *  04-05-2004 Jerry Chen: Initial release
+ *  11-24-2004 Warren Hsu: Add ControlvWriteByte,ControlvReadByte,
+ * ControlvMaskByte
  *
  */
 
-- 
2.7.4

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


Re: [linux-next:master 1892/3082] drivers/staging/lustre/lustre/llite/xattr.c:309:24: warning: unused variable 'lli'

2016-08-22 Thread James Simmons

> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git 
> master
> head:   d18b09e429ad4520272dcdcd8faa01aabc171fd0
> commit: 1e1f9ff406fd5f6003a5dab2ab5a26c4c5bb8cbd [1892/3082] staging: lustre: 
> llite: break ll_getxattr_common into 2 functions
> config: x86_64-randconfig-s3-08200515 (attached as .config)
> compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> git checkout 1e1f9ff406fd5f6003a5dab2ab5a26c4c5bb8cbd
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> All warnings (new ones prefixed by >>):
> 
>drivers/staging/lustre/lustre/llite/xattr.c: In function 
> 'll_getxattr_common':
> >> drivers/staging/lustre/lustre/llite/xattr.c:309:24: warning: unused 
> >> variable 'lli' [-Wunused-variable]
>  struct ll_inode_info *lli = ll_i2info(inode);
>^~~

Besides this warning Oleg found in testing a regression with the new 
xattr hander code that I didn't see  so this coming weekend I will 
investigate and with that fix include this cleanup.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [lustre-devel] [PATCH] staging: lustre: mdc: fix NULL pointer dereference in mdc_adjust_dirpages

2016-08-22 Thread Dilger, Andreas
On Aug 22, 2016, at 10:57, James Simmons  wrote:
> 
> The function mdc_adjust_dirpages is only called on platforms which
> don't have pages 4K in size which is why kbuild only reported this
> for platforms like the Alpha. The problem was a typo in ordering of
> variables in the beginning of a while loop. We were accessing the
> dp pointer before it was kmapped.
> 
> Signed-off-by: James Simmons 

Reviewed-by: Andreas Dilger 

> ---
> drivers/staging/lustre/lustre/mdc/mdc_request.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c 
> b/drivers/staging/lustre/lustre/mdc/mdc_request.c
> index 88848d8..7a182be 100644
> --- a/drivers/staging/lustre/lustre/mdc/mdc_request.c
> +++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c
> @@ -1133,9 +1133,9 @@ static void mdc_adjust_dirpages(struct page **pages, 
> int cfs_pgs, int lu_pgs)
>   int i;
> 
>   for (i = 0; i < cfs_pgs; i++) {
> + struct lu_dirpage *dp = kmap(pages[i]);
>   __u64 hash_end = le64_to_cpu(dp->ldp_hash_end);
>   __u32 flags = le32_to_cpu(dp->ldp_flags);
> - struct lu_dirpage *dp = kmap(pages[i]);
>   struct lu_dirpage *first = dp;
>   struct lu_dirent *end_dirent = NULL;
>   struct lu_dirent *ent;
> -- 
> 1.7.1
> 
> ___
> lustre-devel mailing list
> lustre-de...@lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org

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


Re: [PATCH 2/2] staging: android: ion: Remove valid_handle variable in ion_free_nolock

2016-08-22 Thread Laura Abbott

On 08/22/2016 03:26 AM, Johanna Abrahamsson wrote:

It is not neccessary to save the value of ion_handle_validate since it
is only used once.



Acked-by: Laura Abbott 


Signed-off-by: Johanna Abrahamsson 
---
 drivers/staging/android/ion/ion.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index d209bda..7c5cd5b 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -548,11 +548,7 @@ EXPORT_SYMBOL(ion_alloc);
 static void ion_free_nolock(struct ion_client *client,
struct ion_handle *handle)
 {
-   bool valid_handle;
-
-   valid_handle = ion_handle_validate(client, handle);
-
-   if (!valid_handle) {
+   if (!ion_handle_validate(client, handle)) {
WARN(1, "%s: invalid handle passed to free.\n", __func__);
return;
}



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


Re: [PATCH 1/2] staging: android: ion: Do not BUG on handle client mismatch

2016-08-22 Thread Laura Abbott

On 08/22/2016 03:26 AM, Johanna Abrahamsson wrote:

The ion_free() and ion_free_nolock() functions should not BUG on a
handle client mismatch. It is not necessary to explicitly check for that
mismatch when ion_handle_validate is used.



The validate and BUG_ON are checking two slightly different things.
The BUG_ON is trying to catch blatantly wrong kernel users while the
validate is designed to catch races.

I'd like to keep the BUG_ON in ion_free but it's fine to get rid of
it in ion_free_nolock.

Thanks,
Laura


Signed-off-by: Johanna Abrahamsson 
---
 drivers/staging/android/ion/ion.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 291d5b8..d209bda 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -550,8 +550,6 @@ static void ion_free_nolock(struct ion_client *client,
 {
bool valid_handle;

-   BUG_ON(client != handle->client);
-
valid_handle = ion_handle_validate(client, handle);

if (!valid_handle) {
@@ -563,8 +561,6 @@ static void ion_free_nolock(struct ion_client *client,

 void ion_free(struct ion_client *client, struct ion_handle *handle)
 {
-   BUG_ON(client != handle->client);
-
mutex_lock(>lock);
ion_free_nolock(client, handle);
mutex_unlock(>lock);



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


[PATCH] staging: lustre: mdc: fix NULL pointer dereference in mdc_adjust_dirpages

2016-08-22 Thread James Simmons
The function mdc_adjust_dirpages is only called on platforms which
don't have pages 4K in size which is why kbuild only reported this
for platforms like the Alpha. The problem was a typo in ordering of
variables in the beginning of a while loop. We were accessing the
dp pointer before it was kmapped.

Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/mdc/mdc_request.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c 
b/drivers/staging/lustre/lustre/mdc/mdc_request.c
index 88848d8..7a182be 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_request.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c
@@ -1133,9 +1133,9 @@ static void mdc_adjust_dirpages(struct page **pages, int 
cfs_pgs, int lu_pgs)
int i;
 
for (i = 0; i < cfs_pgs; i++) {
+   struct lu_dirpage *dp = kmap(pages[i]);
__u64 hash_end = le64_to_cpu(dp->ldp_hash_end);
__u32 flags = le32_to_cpu(dp->ldp_flags);
-   struct lu_dirpage *dp = kmap(pages[i]);
struct lu_dirpage *first = dp;
struct lu_dirent *end_dirent = NULL;
struct lu_dirent *ent;
-- 
1.7.1

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


[PATCH 2/2] staging: vt6655: rxtx.c: Fix checkpatch warning

2016-08-22 Thread Anson Jacob
Fix checkpatch.pl warning for trailing */ on a separate line
Remove '+' postfix and '-' prefix from the start and end of block comments

Signed-off-by: Anson Jacob 
---
 drivers/staging/vt6655/rxtx.c | 41 -
 1 file changed, 24 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/vt6655/rxtx.c b/drivers/staging/vt6655/rxtx.c
index e4c3165..890d108 100644
--- a/drivers/staging/vt6655/rxtx.c
+++ b/drivers/staging/vt6655/rxtx.c
@@ -64,8 +64,10 @@
 /*-  Static Functions  --*/
 
 /*-  Static Definitions -*/
-#define CRITICAL_PACKET_LEN  256/* if packet size < 256 -> in-direct 
send
-packet size >= 256 -> direct send 
*/
+/* if packet size < 256 -> in-direct send
+ * vpacket size >= 256 -> direct send
+ */
+#define CRITICAL_PACKET_LEN  256
 
 static const unsigned short wTimeStampOff[2][MAX_RATE] = {
{384, 288, 226, 209, 54, 43, 37, 31, 28, 25, 24, 23}, /* Long Preamble 
*/
@@ -158,11 +160,11 @@ static __le16 vnt_time_stamp_off(struct vnt_private 
*priv, u16 rate)
[rate % MAX_RATE]);
 }
 
-/*byPktType : PK_TYPE_11A 0
-  PK_TYPE_11B 1
-  PK_TYPE_11GB2
-  PK_TYPE_11GA3
-*/
+/* byPktType : PK_TYPE_11A 0
+ * PK_TYPE_11B 1
+ * PK_TYPE_11GB2
+ * PK_TYPE_11GA3
+ */
 static
 unsigned int
 s_uGetTxRsvTime(
@@ -650,13 +652,16 @@ s_vFillRTSHead(
return;
 
if (bDisCRC) {
-   /* When CRCDIS bit is on, H/W forgot to generate FCS for RTS 
frame,
-in this case we need to decrease its length by 4. */
+   /* When CRCDIS bit is on, H/W forgot to generate FCS for
+* RTS frame, in this case we need to decrease its length by 4.
+*/
uRTSFrameLen -= 4;
}
 
-   /* Note: So far RTSHead doesn't appear in ATIM & Beacom DMA, so we 
don't need to take them into account.
-  Otherwise, we need to modify codes for them. */
+   /* Note: So far RTSHead doesn't appear in ATIM & Beacom DMA,
+* so we don't need to take them into account.
+* Otherwise, we need to modify codes for them.
+*/
if (byPktType == PK_TYPE_11GB || byPktType == PK_TYPE_11GA) {
if (byFBOption == AUTO_FB_NONE) {
struct vnt_rts_g *buf = pvRTS;
@@ -842,8 +847,9 @@ s_vFillCTSHead(
return;
 
if (bDisCRC) {
-   /* When CRCDIS bit is on, H/W forgot to generate FCS for CTS 
frame,
-in this case we need to decrease its length by 4. */
+   /* When CRCDIS bit is on, H/W forgot to generate FCS for
+* CTS frame, in this case we need to decrease its length by 4.
+*/
uCTSFrameLen -= 4;
}
 
@@ -915,7 +921,7 @@ s_vFillCTSHead(
}
 }
 
-/*+
+/*
  *
  * Description:
  *  Generate FIFO control for MAC & Baseband controller
@@ -937,7 +943,8 @@ s_vFillCTSHead(
  * Return Value: none
  *
  -
- * unsigned int cbFrameSize, Hdr+Payload+FCS */
+ * unsigned int cbFrameSize, Hdr+Payload+FCS
+ */
 static
 void
 s_vGenerateTxParameter(
@@ -972,8 +979,8 @@ s_vGenerateTxParameter(
return;
 
if (byPktType == PK_TYPE_11GB || byPktType == PK_TYPE_11GA) {
-   if (pvRTS != NULL) { /* RTS_need
-Fill RsvTime */
+   if (pvRTS != NULL) { /* RTS_need */
+   /* Fill RsvTime */
struct vnt_rrv_time_rts *buf = pvRrvTime;
 
buf->rts_rrv_time_aa = s_uGetRTSCTSRsvTime(pDevice, 2, 
byPktType, cbFrameSize, wCurrentRate);
-- 
2.7.4

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


[PATCH 1/2] staging: vt6655: rf.c: Fix checkpatch warning

2016-08-22 Thread Anson Jacob
Fix checkpatch.pl warning for trailing */ on a separate line
Remove '+' postfix and '-' prefix from the start and end of block comments

Signed-off-by: Anson Jacob 
---
 drivers/staging/vt6655/rf.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/vt6655/rf.c b/drivers/staging/vt6655/rf.c
index ae10da2..447882c 100644
--- a/drivers/staging/vt6655/rf.c
+++ b/drivers/staging/vt6655/rf.c
@@ -169,7 +169,8 @@ static unsigned long dwAL2230PowerTable[AL2230_PWR_IDX_LEN] 
= {
 };
 
 /* 40MHz reference frequency
- * Need to Pull PLLON(PE3) low when writing channel registers through 3-wire.*/
+ * Need to Pull PLLON(PE3) low when writing channel registers through 3-wire.
+ */
 static const unsigned long dwAL7230InitTable[CB_AL7230_INIT_SEQ] = {
0x00379000+(BY_AL7230_REG_LEN<<3)+IFREGCTL_REGW, /* Channel1 // Need 
modify for 11a */
0x1100+(BY_AL7230_REG_LEN<<3)+IFREGCTL_REGW, /* Channel1 // Need 
modify for 11a */
@@ -463,7 +464,8 @@ static bool s_bAL7230Init(struct vnt_private *priv)
 }
 
 /* Need to Pull PLLON low when writing channel registers through
- * 3-wire interface */
+ * 3-wire interface
+ */
 static bool s_bAL7230SelectChannel(struct vnt_private *priv, unsigned char 
byChannel)
 {
void __iomem *dwIoBase = priv->PortOffset;
@@ -873,7 +875,8 @@ bool RFbRawSetPower(
 
case RF_AIROHA7230:
/* 0x080F1B00 for 3 wire control TxGain(D10)
-* and 0x31 as TX Gain value */
+* and 0x31 as TX Gain value
+*/
dwMax7230Pwr = 0x080C0B00 | ((byPwr) << 12) |
(BY_AL7230_REG_LEN << 3)  | IFREGCTL_REGW;
 
@@ -886,7 +889,7 @@ bool RFbRawSetPower(
return ret;
 }
 
-/*+
+/*
  *
  * Routine Description:
  * Translate RSSI to dBm
@@ -900,7 +903,7 @@ bool RFbRawSetPower(
  *
  * Return Value: none
  *
- -*/
+ */
 void
 RFvRSSITodBm(
struct vnt_private *priv,
@@ -927,7 +930,8 @@ RFvRSSITodBm(
 }
 
 /* Post processing for the 11b/g and 11a.
- * for save time on changing Reg2,3,5,7,10,12,15 */
+ * for save time on changing Reg2,3,5,7,10,12,15
+ */
 bool RFbAL7230SelectChannelPostProcess(struct vnt_private *priv,
   u16 byOldChannel,
   u16 byNewChannel)
@@ -938,7 +942,8 @@ bool RFbAL7230SelectChannelPostProcess(struct vnt_private 
*priv,
 
/* if change between 11 b/g and 11a need to update the following
 * register
-* Channel Index 1~14 */
+* Channel Index 1~14
+*/
if ((byOldChannel <= CB_MAX_CHANNEL_24G) && (byNewChannel > 
CB_MAX_CHANNEL_24G)) {
/* Change from 2.4G to 5G [Reg] */
ret &= IFRFbWriteEmbedded(priv, dwAL7230InitTableAMode[2]);
-- 
2.7.4

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


[PATCH 0/2] staging: vt6655: fix checkpatch warning for trailing */ on a separate line

2016-08-22 Thread Anson Jacob
*** BLURB HERE ***

Anson Jacob (2):
  staging: vt6655: rf.c: Fix checkpatch warning
  staging: vt6655: rxtx.c: Fix checkpatch warning

 drivers/staging/vt6655/rf.c   | 19 ---
 drivers/staging/vt6655/rxtx.c | 41 -
 2 files changed, 36 insertions(+), 24 deletions(-)

-- 
2.7.4

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


[PATCH] staging: rts5208: rtsx.c: Fix checkpatch warnings.

2016-08-22 Thread MingChia Chung
  This patch fixes a minor checkpatch warnings:

  "WARNING: Block comments use a trailing */ on a separate line"

  Signed-off-by: Ming-Chia Chung 
---
 drivers/staging/rts5208/rtsx.c | 42 --
 1 file changed, 28 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx.c b/drivers/staging/rts5208/rtsx.c
index e992e03..a880411 100644
--- a/drivers/staging/rts5208/rtsx.c
+++ b/drivers/staging/rts5208/rtsx.c
@@ -81,14 +81,16 @@ static int slave_alloc(struct scsi_device *sdev)
 
 static int slave_configure(struct scsi_device *sdev)
 {
-   /* Scatter-gather buffers (all but the last) must have a length
+   /*
+   * Scatter-gather buffers (all but the last) must have a length
 * divisible by the bulk maxpacket size.  Otherwise a data packet
 * would end up being short, causing a premature end to the data
 * transfer.  Since high-speed bulk pipes have a maxpacket size
 * of 512, we'll use that as the scsi device queue's DMA alignment
 * mask.  Guaranteeing proper alignment of the first buffer will
 * have the desired effect because, except at the beginning and
-* the end, scatter-gather buffers follow page boundaries. */
+* the end, scatter-gather buffers follow page boundaries.
+   */
blk_queue_dma_alignment(sdev->request_queue, (512 - 1));
 
/* Set the SCSI level to at least 2.  We'll leave it at 3 if that's
@@ -185,8 +187,10 @@ static int command_abort(struct scsi_cmnd *srb)
return SUCCESS;
 }
 
-/* This invokes the transport reset mechanism to reset the state of the
- * device */
+/*
+ * This invokes the transport reset mechanism to reset the state of the
+ * device
+ */
 static int device_reset(struct scsi_cmnd *srb)
 {
int result = 0;
@@ -654,15 +658,19 @@ static void rtsx_release_resources(struct rtsx_dev *dev)
kfree(dev->chip);
 }
 
-/* First stage of disconnect processing: stop all commands and remove
- * the host */
+/*
+ * First stage of disconnect processing: stop all commands and remove
+ * the host
+ */
 static void quiesce_and_remove_host(struct rtsx_dev *dev)
 {
struct Scsi_Host *host = rtsx_to_host(dev);
struct rtsx_chip *chip = dev->chip;
 
-   /* Prevent new transfers, stop the current command, and
-* interrupt a SCSI-scan or device-reset delay */
+   /*
+   * Prevent new transfers, stop the current command, and
+* interrupt a SCSI-scan or device-reset delay
+   */
mutex_lock(>dev_mutex);
scsi_lock(host);
rtsx_set_stat(chip, RTSX_STAT_DISCONNECT);
@@ -674,9 +682,11 @@ static void quiesce_and_remove_host(struct rtsx_dev *dev)
/* Wait some time to let other threads exist */
wait_timeout(100);
 
-   /* queuecommand won't accept any new commands and the control
+   /*
+   * queuecommand won't accept any new commands and the control
 * thread won't execute a previously-queued command.  If there
-* is such a command pending, complete it with an error. */
+* is such a command pending, complete it with an error.
+   */
mutex_lock(>dev_mutex);
if (chip->srb) {
chip->srb->result = DID_NO_CONNECT << 16;
@@ -696,8 +706,10 @@ static void release_everything(struct rtsx_dev *dev)
 {
rtsx_release_resources(dev);
 
-   /* Drop our reference to the host; the SCSI core will free it
-* when the refcount becomes 0. */
+   /*
+   * Drop our reference to the host; the SCSI core will free it
+* when the refcount becomes 0.
+   */
scsi_host_put(rtsx_to_host(dev));
 }
 
@@ -936,8 +948,10 @@ static int rtsx_probe(struct pci_dev *pci,
 
rtsx_init_chip(dev->chip);
 
-   /* set the supported max_lun and max_id for the scsi host
-* NOTE: the minimal value of max_id is 1 */
+   /*
+   * set the supported max_lun and max_id for the scsi host
+* NOTE: the minimal value of max_id is 1
+   */
host->max_id = 1;
host->max_lun = dev->chip->max_lun;
 
-- 
2.9.2

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


Re: [staging:staging-testing 201/347] drivers/staging/lustre/lustre/mdc/mdc_request.c:1243:32: error: 'dp' undeclared

2016-08-22 Thread James Simmons

> On Mon, Aug 22, 2016 at 03:15:23PM +0800, kbuild test robot wrote:
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
> > staging-testing
> > head:   f5a9a15f8fd4168e415e94f5dce367f3cef08e03
> > commit: 4f76f0ec093c2f9ef049495c78d486bfb48e4de0 [201/347] staging: lustre: 
> > llite: move dir cache to MDC layer
> > config: alpha-allyesconfig (attached as .config)
> > compiler: alpha-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
> > reproduce:
> > wget 
> > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> >  -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > git checkout 4f76f0ec093c2f9ef049495c78d486bfb48e4de0
> > # save the attached .config to linux build tree
> > make.cross ARCH=alpha 
> 
> Odd, I can't duplicate this on x86, what's so strange about alpha?

I see what the problem is. Its one of those 64K page versus 4K page 
issues. I will send a patch right away.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 5/5] staging: i4l: icn: fix incorrect type of arguments

2016-08-22 Thread Sudip Mukherjee
sparse was warning about incorrect type of argument:

drivers/staging/i4l/icn/icn.c:1048:49:
warning: incorrect type in argument 2 (different address spaces)
drivers/staging/i4l/icn/icn.c:1048:49:
expected void const [noderef] *from
drivers/staging/i4l/icn/icn.c:1048:49:
got unsigned char const [usertype] *buf
drivers/staging/i4l/icn/icn.c:1476:38:
warning: incorrect type in argument 1 (different address spaces)
drivers/staging/i4l/icn/icn.c:1476:38:
expected unsigned char const [usertype] *buf
drivers/staging/i4l/icn/icn.c:1476:38:
got unsigned char const [noderef] [usertype] *buf

The function icn_writecmd() was used to copy from userspace and also
from the kernelspace. Add another argument to the function to have two
separate pointers, one for the userspace and one for the kernelspace.
Based on the value of user as passed from the caller we use one of
the two pointers.

Signed-off-by: Sudip Mukherjee 
---
 drivers/staging/i4l/icn/icn.c | 35 +--
 1 file changed, 21 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/i4l/icn/icn.c b/drivers/staging/i4l/icn/icn.c
index 45623fa..fa705db 100644
--- a/drivers/staging/i4l/icn/icn.c
+++ b/drivers/staging/i4l/icn/icn.c
@@ -1022,7 +1022,8 @@ icn_readstatus(u_char __user *buf, int len, icn_card 
*card)
 
 /* Put command-strings into the command-queue of the Interface */
 static int
-icn_writecmd(const u_char *buf, int len, int user, icn_card *card)
+icn_writecmd(const u_char __user *ubuf, const u_char *kbuf, int len,
+int user, icn_card *card)
 {
int mch = card->secondhalf ? 2 : 0;
int pp;
@@ -1045,10 +1046,10 @@ icn_writecmd(const u_char *buf, int len, int user, 
icn_card *card)
if (count > len)
count = len;
if (user) {
-   if (copy_from_user(msg, buf, count))
+   if (copy_from_user(msg, ubuf, count))
return -EFAULT;
} else
-   memcpy(msg, buf, count);
+   memcpy(msg, kbuf, count);
 
spin_lock_irqsave(, flags);
lastmap_card = dev.mcard;
@@ -1274,7 +1275,9 @@ icn_command(isdn_ctrl *c, icn_card *card)
msleep_interruptible(ICN_BOOT_TIMEOUT1);
sprintf(cbuf, 
"00;FV2ON\n01;EAZ%c\n02;EAZ%c\n",
(a & 1) ? '1' : 'C', (a & 2) ? 
'2' : 'C');
-   i = icn_writecmd(cbuf, strlen(cbuf), 0, 
card);
+   i = icn_writecmd(NULL, cbuf,
+strlen(cbuf),
+0, card);
printk(KERN_INFO
   "icn: (%s) Leased-line mode 
enabled\n",
   CID);
@@ -1287,7 +1290,9 @@ icn_command(isdn_ctrl *c, icn_card *card)
if (card->leased) {
card->leased = 0;
sprintf(cbuf, "00;FV2OFF\n");
-   i = icn_writecmd(cbuf, strlen(cbuf), 0, 
card);
+   i = icn_writecmd(NULL, cbuf,
+strlen(cbuf),
+0, card);
printk(KERN_INFO
   "icn: (%s) Leased-line mode 
disabled\n",
   CID);
@@ -1324,7 +1329,7 @@ icn_command(isdn_ctrl *c, icn_card *card)
 "%02d;D%s_R%s,%02d,%02d,%s\n", (int)(a + 1),
 dcode, p, c->parm.setup.si1,
 c->parm.setup.si2, c->parm.setup.eazmsn);
-   i = icn_writecmd(cbuf, strlen(cbuf), 0, card);
+   i = icn_writecmd(NULL, cbuf, strlen(cbuf), 0, card);
}
break;
case ISDN_CMD_ACCEPTD:
@@ -1341,10 +1346,12 @@ icn_command(isdn_ctrl *c, icn_card *card)
sprintf(cbuf, "%02d;BTRA\n", (int)a);
break;
}
-   i = icn_writecmd(cbuf, strlen(cbuf), 0, card);
+   i = icn_writecmd(NULL, cbuf,
+strlen(cbuf), 0,
+card);
}
sprintf(cbuf, "%02d;DCON_R\n", (int)a);
-   i = icn_writecmd(cbuf, strlen(cbuf), 0, card);
+   i = icn_writecmd(NULL, cbuf, 

[PATCH 4/5] staging: i4l: icn: remove blank lines

2016-08-22 Thread Sudip Mukherjee
Blank lines are not needed after starting brace or before a closing
brace.

Signed-off-by: Sudip Mukherjee 
---
 drivers/staging/i4l/icn/icn.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/i4l/icn/icn.c b/drivers/staging/i4l/icn/icn.c
index 1f72884..45623fa 100644
--- a/drivers/staging/i4l/icn/icn.c
+++ b/drivers/staging/i4l/icn/icn.c
@@ -82,7 +82,6 @@ icn_shiftout(unsigned short port,
 int firstbit,
 int bitcount)
 {
-
register u_char s;
register u_char c;
 
@@ -475,7 +474,6 @@ icn_parse_status(u_char *status, int channel, icn_card 
*card)
 
if (card->flags &
((channel) ? ICN_FLAGS_B2ACTIVE : ICN_FLAGS_B1ACTIVE)) {
-
isdn_ctrl ncmd;
 
card->flags &= ~((channel) ?
@@ -661,7 +659,6 @@ icn_polldchan(unsigned long data)
vstr[3] = '\0';
card->fw_rev = 
(int)simple_strtoul(vstr, NULL, 10);
continue;
-
}
}
} else {
-- 
1.9.1

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


[PATCH 3/5] staging: i4l: icn: space not needed after cast

2016-08-22 Thread Sudip Mukherjee
No need provide a space after a typecast.

Signed-off-by: Sudip Mukherjee 
---
 drivers/staging/i4l/icn/icn.c | 66 +--
 1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/drivers/staging/i4l/icn/icn.c b/drivers/staging/i4l/icn/icn.c
index b2f4055..1f72884 100644
--- a/drivers/staging/i4l/icn/icn.c
+++ b/drivers/staging/i4l/icn/icn.c
@@ -87,7 +87,7 @@ icn_shiftout(unsigned short port,
register u_char c;
 
for (s = firstbit, c = bitcount; c > 0; s--, c--)
-   OUTB_P((u_char) ((val >> s) & 1) ? 0xff : 0, port);
+   OUTB_P((u_char)((val >> s) & 1) ? 0xff : 0, port);
 }
 
 /*
@@ -385,7 +385,7 @@ icn_pollbchan_send(int channel, icn_card *card)
 static void
 icn_pollbchan(unsigned long data)
 {
-   icn_card *card = (icn_card *) data;
+   icn_card *card = (icn_card *)data;
unsigned long flags;
 
if (card->flags & ICN_FLAGS_B1ACTIVE) {
@@ -547,7 +547,7 @@ icn_parse_status(u_char *status, int channel, icn_card 
*card)
break;
case 6:
snprintf(cmd.parm.num, sizeof(cmd.parm.num), "%d",
-(int) simple_strtoul(status + 7, NULL, 16));
+(int)simple_strtoul(status + 7, NULL, 16));
break;
case 7:
status += 3;
@@ -607,7 +607,7 @@ icn_putmsg(icn_card *card, unsigned char c)
 static void
 icn_polldchan(unsigned long data)
 {
-   icn_card *card = (icn_card *) data;
+   icn_card *card = (icn_card *)data;
int mch = card->secondhalf ? 2 : 0;
int avail = 0;
int left;
@@ -659,7 +659,7 @@ icn_polldchan(unsigned long data)
*q = '\0';
strcat(vstr, "000");
vstr[3] = '\0';
-   card->fw_rev = (int) 
simple_strtoul(vstr, NULL, 10);
+   card->fw_rev = 
(int)simple_strtoul(vstr, NULL, 10);
continue;
 
}
@@ -686,7 +686,7 @@ icn_polldchan(unsigned long data)
card->flags |= ICN_FLAGS_RBTIMER;
del_timer(>rb_timer);
card->rb_timer.function = icn_pollbchan;
-   card->rb_timer.data = (unsigned long) card;
+   card->rb_timer.data = (unsigned long)card;
card->rb_timer.expires = jiffies + ICN_TIMER_BCREAD;
add_timer(>rb_timer);
}
@@ -808,7 +808,7 @@ icn_loadboot(u_char __user *buffer, icn_card *card)
unsigned long flags;
 
 #ifdef BOOT_DEBUG
-   printk(KERN_DEBUG "icn_loadboot called, buffaddr=%08lx\n", (ulong) 
buffer);
+   printk(KERN_DEBUG "icn_loadboot called, buffaddr=%08lx\n", 
(ulong)buffer);
 #endif
codebuf = kmalloc(ICN_CODE_STAGE1, GFP_KERNEL);
if (!codebuf) {
@@ -1193,28 +1193,28 @@ icn_command(isdn_ctrl *c, icn_card *card)
}
break;
case ICN_IOCTL_GETMMIO:
-   return (long) dev.memaddr;
+   return (long)dev.memaddr;
case ICN_IOCTL_SETPORT:
if (a == 0x300 || a == 0x310 || a == 0x320 || a == 0x330
|| a == 0x340 || a == 0x350 || a == 0x360 ||
a == 0x308 || a == 0x318 || a == 0x328 || a == 0x338
|| a == 0x348 || a == 0x358 || a == 0x368) {
-   if (card->port != (unsigned short) a) {
-   if (!request_region((unsigned short) a, 
ICN_PORTLEN, "icn-isdn")) {
+   if (card->port != (unsigned short)a) {
+   if (!request_region((unsigned short)a, 
ICN_PORTLEN, "icn-isdn")) {
printk(KERN_WARNING
   "icn: (%s) ports 
0x%03x-0x%03x in use.\n",
-  CID, (int) a, (int) a + 
ICN_PORTLEN);
+  CID, (int)a, (int)a + 
ICN_PORTLEN);
return -EINVAL;
}
-   release_region((unsigned short) a, 
ICN_PORTLEN);
+   release_region((unsigned short)a, 
ICN_PORTLEN);
icn_stopcard(card);
spin_lock_irqsave(>lock, flags);
if (card->rvalid)
release_region(card->port, 
ICN_PORTLEN);
-  

[PATCH 2/5] staging: i4l: act2000: remove unused macro

2016-08-22 Thread Sudip Mukherjee
The macro EVAL_PLCI and MAKE_PLCI are not being used. Remove them.
But keep the comment preceding them as it contains information
regarding message format.

Signed-off-by: Sudip Mukherjee 
---
 drivers/staging/i4l/act2000/capi.h | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/staging/i4l/act2000/capi.h 
b/drivers/staging/i4l/act2000/capi.h
index 7d0f52d..34884a5 100644
--- a/drivers/staging/i4l/act2000/capi.h
+++ b/drivers/staging/i4l/act2000/capi.h
@@ -127,13 +127,6 @@ typedef struct actcapi_ncpd {
  * Bit 5-7  = Controller
  * Bit 8-15 = reserved (must be 0)
  */
-#define MAKE_PLCI(plci, contr) \
-   ((plci & 0x1f) | ((contr & 0x7) << 5))
-
-#define EVAL_PLCI(fakeplci, plci, contr) { \
-   plci  = fakeplci & 0x1f;\
-   contr = (fakeplci >> 5) & 0x7;  \
-   }
 
 typedef struct actcapi_msg {
actcapi_msghdr hdr;
-- 
1.9.1

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


[PATCH 1/5] staging: i4l: act2000: remove unused argument

2016-08-22 Thread Sudip Mukherjee
The macro EVAL_NCCI was only being used in capi.c and the argument
controller was not used. Remove the argument and at the same time
remove the variable which now becomes unused.

Signed-off-by: Sudip Mukherjee 
---
 drivers/staging/i4l/act2000/capi.c | 3 +--
 drivers/staging/i4l/act2000/capi.h | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/i4l/act2000/capi.c 
b/drivers/staging/i4l/act2000/capi.c
index 3f66ca2..41b4d19 100644
--- a/drivers/staging/i4l/act2000/capi.c
+++ b/drivers/staging/i4l/act2000/capi.c
@@ -547,12 +547,11 @@ static int
 actcapi_data_b3_ind(act2000_card *card, struct sk_buff *skb) {
__u16 plci;
__u16 ncci;
-   __u16 controller;
__u8  blocknr;
int chan;
actcapi_msg *msg = (actcapi_msg *)skb->data;
 
-   EVAL_NCCI(msg->msg.data_b3_ind.fakencci, plci, controller, ncci);
+   EVAL_NCCI(msg->msg.data_b3_ind.fakencci, plci, ncci);
chan = find_ncci(card, ncci);
if (chan < 0)
return 0;
diff --git a/drivers/staging/i4l/act2000/capi.h 
b/drivers/staging/i4l/act2000/capi.h
index 01ccdec..7d0f52d 100644
--- a/drivers/staging/i4l/act2000/capi.h
+++ b/drivers/staging/i4l/act2000/capi.h
@@ -114,9 +114,8 @@ typedef struct actcapi_ncpd {
 #define MAKE_NCCI(plci, contr, ncci)   \
((plci & 0x1f) | ((contr & 0x7) << 5) | ((ncci & 0xff) << 8))
 
-#define EVAL_NCCI(fakencci, plci, contr, ncci) {   \
+#define EVAL_NCCI(fakencci, plci, ncci) {  \
plci  = fakencci & 0x1f;\
-   contr = (fakencci >> 5) & 0x7;  \
ncci  = (fakencci >> 8) & 0xff; \
}
 
-- 
1.9.1

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


[PATCH 0/2] hyperv: minor cleanups

2016-08-22 Thread sthemmin
From: Stephen Hemminger 

Sparse warnings from global data/functions that should be static

Stephen Hemminger (2):
  hyperv: make mmio resource local
  hv_pci: make hv_irq functions static

 drivers/hv/vmbus_drv.c|4 ++--
 drivers/pci/host/pci-hyperv.c |4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

-- 
1.7.4.1

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


[PATCH 1/2] hyperv: make mmio resource local

2016-08-22 Thread sthemmin
From: Stephen Hemminger 

This fixes a sparse warning because hyperv_mmio resources
are only used in this one file and should be static.

Signed-off-by: Stephen Hemminger 
---
 drivers/hv/vmbus_drv.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index e82f7e1..954d16a 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -105,8 +105,8 @@ static struct notifier_block hyperv_panic_block = {
 
 static const char *fb_mmio_name = "fb_range";
 static struct resource *fb_mmio;
-struct resource *hyperv_mmio;
-DEFINE_SEMAPHORE(hyperv_mmio_lock);
+static struct resource *hyperv_mmio;
+static DEFINE_SEMAPHORE(hyperv_mmio_lock);
 
 static int vmbus_exists(void)
 {
-- 
1.7.4.1

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


[PATCH 2/2] hv_pci: make hv_irq functions static

2016-08-22 Thread sthemmin
From: Stephen Hemminger 

Fix sparse warning because these functions only used in one file.

Signed-off-by: Stephen Hemminger 
---
 drivers/pci/host/pci-hyperv.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index 6955ffdb..1ebe2b0 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -755,7 +755,7 @@ static int hv_set_affinity(struct irq_data *data, const 
struct cpumask *dest,
return parent->chip->irq_set_affinity(parent, dest, force);
 }
 
-void hv_irq_mask(struct irq_data *data)
+static void hv_irq_mask(struct irq_data *data)
 {
pci_msi_mask_irq(data);
 }
@@ -770,7 +770,7 @@ void hv_irq_mask(struct irq_data *data)
  * is built out of this PCI bus's instance GUID and the function
  * number of the device.
  */
-void hv_irq_unmask(struct irq_data *data)
+static void hv_irq_unmask(struct irq_data *data)
 {
struct msi_desc *msi_desc = irq_data_get_msi_desc(data);
struct irq_cfg *cfg = irqd_cfg(data);
-- 
1.7.4.1

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


Re: [PATCH] rtlwifi: Fix missing country code for Great Britain

2016-08-22 Thread Kalle Valo
Larry Finger  writes:

> Some RTL8821AE devices sold in Great Britain have the country code of
> 0x25 encoded in their EEPROM. This value is not tested in the routine
> that establishes the regulatory info for the chip. The fix is to set
> this code to have the same capabilities as the EU countries.
>
> Signed-off-by: Larry Finger 
> Cc: Stable 

[...]

> --- a/drivers/net/wireless/realtek/rtlwifi/regd.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/regd.c
> @@ -345,9 +345,9 @@ static const struct ieee80211_regdomain 
> *_rtl_regdomain_select(
>   return _regdom_no_midband;
>   case COUNTRY_CODE_IC:
>   return _regdom_11;
> - case COUNTRY_CODE_ETSI:
>   case COUNTRY_CODE_TELEC_NETGEAR:
>   return _regdom_60_64;
> + case COUNTRY_CODE_ETSI:
>   case COUNTRY_CODE_SPAIN:
>   case COUNTRY_CODE_FRANCE:
>   case COUNTRY_CODE_ISRAEL:

I didn't check the full source, but here you seem to be changing also
the content of ETSI regdomain. The commit log doesn't mention anything
about that so I want to double check that this is really intentionally.

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


[PATCH] staging: most: aim-cdev: destroy ida struct in case of exception

2016-08-22 Thread Christian Gromm
This patch is needed to clean up the initialized ida structure in case
the function exits with an exception.

Signed-off-by: Christian Gromm 
---
 drivers/staging/most/aim-cdev/cdev.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/most/aim-cdev/cdev.c 
b/drivers/staging/most/aim-cdev/cdev.c
index db6f458..1c20ae6 100644
--- a/drivers/staging/most/aim-cdev/cdev.c
+++ b/drivers/staging/most/aim-cdev/cdev.c
@@ -509,7 +509,7 @@ static int __init mod_init(void)
 
err = alloc_chrdev_region(_devno, 0, 50, "cdev");
if (err < 0)
-   return err;
+   goto dest_ida;
major = MAJOR(aim_devno);
 
aim_class = class_create(THIS_MODULE, "most_cdev_aim");
@@ -527,6 +527,8 @@ dest_class:
class_destroy(aim_class);
 free_cdev:
unregister_chrdev_region(aim_devno, 1);
+dest_ida:
+   ida_destroy(_id);
return err;
 }
 
-- 
1.9.1

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


Re: linux-4.8-rc3/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c:3533: pointless test ?

2016-08-22 Thread Greg KH
On Mon, Aug 22, 2016 at 03:07:44PM +0100, David Binderman wrote:
> Hello there,
> 
> linux-4.8-rc3/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c:3533]:
> (style) Condition 'pBtMgnt.ExtConfig.HCIExtensionVer>=1' is always
> true
> 
> Source code is
> 
> if (pBtMgnt->ExtConfig.HCIExtensionVer < 1) {
> 
> } else if (pBtMgnt->ExtConfig.HCIExtensionVer >= 1) {
> 
> Suggest remove second test.

patches are always welcome :)

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


Re: [PATCH 3/3] drivers: Add visorbus to the drivers/virt directory

2016-08-22 Thread 'Greg KH'
On Mon, Aug 22, 2016 at 10:02:43AM -0400, 'Greg KH' wrote:
> On Mon, Aug 22, 2016 at 10:46:10AM +, Sell, Timothy C wrote:
> > > -Original Message-
> > > From: 'Greg KH' [mailto:gre...@linuxfoundation.org]
> > > Sent: Monday, August 22, 2016 4:16 AM
> > > To: Sell, Timothy C 
> > > Cc: cor...@lwn.net; t...@linutronix.de; mi...@redhat.com;
> > > h...@zytor.com; Arfvidson, Erik ;
> > > hof...@osadl.org; dzic...@redhat.com; jes.soren...@redhat.com; Curtin,
> > > Alexander Paul ;
> > > janani.rvchn...@gmail.com; sudipm.mukher...@gmail.com;
> > > pra...@redhat.com; Binder, David Anthony ;
> > > nhor...@redhat.com; dan.j.willi...@intel.com; linux-
> > > ker...@vger.kernel.org; linux-...@vger.kernel.org; driverdev-
> > > de...@linuxdriverproject.org; *S-Par-Maintainer
> > > ; Kershner, David A
> > > 
> > > Subject: Re: [PATCH 3/3] drivers: Add visorbus to the drivers/virt 
> > > directory
> > > 
> > > oh that's funny, I have no idea what happened here, perhaps when I
> > > copied the file into the original email?  Strange things happen while on
> > > planes...
> > > 
> > > Anyway, ok, one comment addressed, great!  Now about the many many
> > > others?
> > 
> > This particular comment happened to affect the credibility of all the other
> > ones, so it needed to be addressed first!
> 
> Oh, so everything else was credible?  Glad to hear it :)

And please, fix your quoting, you quote all of the cc: lines, yet none
of the text?  Odd emailer...

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


linux-4.8-rc3/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c:3533: pointless test ?

2016-08-22 Thread David Binderman
Hello there,

linux-4.8-rc3/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c:3533]:
(style) Condition 'pBtMgnt.ExtConfig.HCIExtensionVer>=1' is always
true

Source code is

if (pBtMgnt->ExtConfig.HCIExtensionVer < 1) {

} else if (pBtMgnt->ExtConfig.HCIExtensionVer >= 1) {

Suggest remove second test.


Regards

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


Re: [PATCH 3/3] drivers: Add visorbus to the drivers/virt directory

2016-08-22 Thread 'Greg KH'
On Mon, Aug 22, 2016 at 10:46:10AM +, Sell, Timothy C wrote:
> > -Original Message-
> > From: 'Greg KH' [mailto:gre...@linuxfoundation.org]
> > Sent: Monday, August 22, 2016 4:16 AM
> > To: Sell, Timothy C 
> > Cc: cor...@lwn.net; t...@linutronix.de; mi...@redhat.com;
> > h...@zytor.com; Arfvidson, Erik ;
> > hof...@osadl.org; dzic...@redhat.com; jes.soren...@redhat.com; Curtin,
> > Alexander Paul ;
> > janani.rvchn...@gmail.com; sudipm.mukher...@gmail.com;
> > pra...@redhat.com; Binder, David Anthony ;
> > nhor...@redhat.com; dan.j.willi...@intel.com; linux-
> > ker...@vger.kernel.org; linux-...@vger.kernel.org; driverdev-
> > de...@linuxdriverproject.org; *S-Par-Maintainer
> > ; Kershner, David A
> > 
> > Subject: Re: [PATCH 3/3] drivers: Add visorbus to the drivers/virt directory
> > 
> > oh that's funny, I have no idea what happened here, perhaps when I
> > copied the file into the original email?  Strange things happen while on
> > planes...
> > 
> > Anyway, ok, one comment addressed, great!  Now about the many many
> > others?
> 
> This particular comment happened to affect the credibility of all the other
> ones, so it needed to be addressed first!

Oh, so everything else was credible?  Glad to hear it :)

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


[PATCH V2] Staging: android: ion: fix parenthesis alignment

2016-08-22 Thread Ben LeMasurier
This fixes remaining checkpatch.pl "Alignment should match open
parenthesis" issues.

Signed-off-by: Ben LeMasurier 
---
V2: Rebased against current staging-testing staging tree.
 drivers/staging/android/ion/ion.c  | 42 +-
 drivers/staging/android/ion/ion_chunk_heap.c   | 12 
 drivers/staging/android/ion/ion_cma_heap.c |  2 +-
 drivers/staging/android/ion/ion_dummy_driver.c | 10 +++---
 drivers/staging/android/ion/ion_page_pool.c|  2 +-
 drivers/staging/android/ion/ion_system_heap.c  | 10 +++---
 6 files changed, 39 insertions(+), 39 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 88dd17e..291d5b8 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -174,10 +174,10 @@ static void ion_buffer_add(struct ion_device *dev,
 
 /* this function should only be called while dev->lock is held */
 static struct ion_buffer *ion_buffer_create(struct ion_heap *heap,
-struct ion_device *dev,
-unsigned long len,
-unsigned long align,
-unsigned long flags)
+   struct ion_device *dev,
+   unsigned long len,
+   unsigned long align,
+   unsigned long flags)
 {
struct ion_buffer *buffer;
struct sg_table *table;
@@ -331,7 +331,7 @@ static void ion_buffer_remove_from_handle(struct ion_buffer 
*buffer)
 }
 
 static struct ion_handle *ion_handle_create(struct ion_client *client,
-struct ion_buffer *buffer)
+   struct ion_buffer *buffer)
 {
struct ion_handle *handle;
 
@@ -421,7 +421,7 @@ static struct ion_handle *ion_handle_lookup(struct 
ion_client *client,
 }
 
 static struct ion_handle *ion_handle_get_by_id_nolock(struct ion_client 
*client,
-   int id)
+ int id)
 {
struct ion_handle *handle;
 
@@ -581,7 +581,7 @@ static void *ion_buffer_kmap_get(struct ion_buffer *buffer)
}
vaddr = buffer->heap->ops->map_kernel(buffer->heap, buffer);
if (WARN_ONCE(vaddr == NULL,
-   "heap->ops->map_kernel should return ERR_PTR on error"))
+ "heap->ops->map_kernel should return ERR_PTR on error"))
return ERR_PTR(-EINVAL);
if (IS_ERR(vaddr))
return vaddr;
@@ -750,7 +750,7 @@ static const struct file_operations debug_client_fops = {
 };
 
 static int ion_get_client_serial(const struct rb_root *root,
-   const unsigned char *name)
+const unsigned char *name)
 {
int serial = -1;
struct rb_node *node;
@@ -839,7 +839,7 @@ struct ion_client *ion_client_create(struct ion_device *dev,
 
path = dentry_path(dev->clients_debug_root, buf, 256);
pr_err("Failed to create client debugfs at %s/%s\n",
-   path, client->display_name);
+  path, client->display_name);
}
 
up_write(>lock);
@@ -907,7 +907,7 @@ static void ion_unmap_dma_buf(struct dma_buf_attachment 
*attachment,
 }
 
 void ion_pages_sync_for_device(struct device *dev, struct page *page,
-   size_t size, enum dma_data_direction dir)
+  size_t size, enum dma_data_direction dir)
 {
struct scatterlist sg;
 
@@ -947,7 +947,7 @@ static void ion_buffer_sync_for_device(struct ion_buffer 
*buffer,
 
if (ion_buffer_page_is_dirty(page))
ion_pages_sync_for_device(dev, ion_buffer_page(page),
-   PAGE_SIZE, dir);
+ PAGE_SIZE, dir);
 
ion_buffer_page_clean(buffer->pages + i);
}
@@ -1025,7 +1025,7 @@ static int ion_mmap(struct dma_buf *dmabuf, struct 
vm_area_struct *vma)
 
if (!buffer->heap->ops->map_user) {
pr_err("%s: this heap does not define a method for mapping to 
userspace\n",
-   __func__);
+  __func__);
return -EINVAL;
}
 
@@ -1116,7 +1116,7 @@ static struct dma_buf_ops dma_buf_ops = {
 };
 
 struct dma_buf *ion_share_dma_buf(struct ion_client *client,
-   struct ion_handle *handle)
+ struct ion_handle *handle)
 {
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
struct ion_buffer *buffer;
@@ -1291,9 +1291,9 @@ static long ion_ioctl(struct file *filp, unsigned int 
cmd, unsigned long arg)

RE: [PATCH 3/3] drivers: Add visorbus to the drivers/virt directory

2016-08-22 Thread Sell, Timothy C
> -Original Message-
> From: 'Greg KH' [mailto:gre...@linuxfoundation.org]
> Sent: Monday, August 22, 2016 4:16 AM
> To: Sell, Timothy C 
> Cc: cor...@lwn.net; t...@linutronix.de; mi...@redhat.com;
> h...@zytor.com; Arfvidson, Erik ;
> hof...@osadl.org; dzic...@redhat.com; jes.soren...@redhat.com; Curtin,
> Alexander Paul ;
> janani.rvchn...@gmail.com; sudipm.mukher...@gmail.com;
> pra...@redhat.com; Binder, David Anthony ;
> nhor...@redhat.com; dan.j.willi...@intel.com; linux-
> ker...@vger.kernel.org; linux-...@vger.kernel.org; driverdev-
> de...@linuxdriverproject.org; *S-Par-Maintainer
> ; Kershner, David A
> 
> Subject: Re: [PATCH 3/3] drivers: Add visorbus to the drivers/virt directory
> 
> oh that's funny, I have no idea what happened here, perhaps when I
> copied the file into the original email?  Strange things happen while on
> planes...
> 
> Anyway, ok, one comment addressed, great!  Now about the many many
> others?

This particular comment happened to affect the credibility of all the other
ones, so it needed to be addressed first!

Tim Sell

> 
> thanks,
> 
> greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 2/2] staging: android: ion: Remove valid_handle variable in ion_free_nolock

2016-08-22 Thread Johanna Abrahamsson
It is not neccessary to save the value of ion_handle_validate since it
is only used once.

Signed-off-by: Johanna Abrahamsson 
---
 drivers/staging/android/ion/ion.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index d209bda..7c5cd5b 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -548,11 +548,7 @@ EXPORT_SYMBOL(ion_alloc);
 static void ion_free_nolock(struct ion_client *client,
struct ion_handle *handle)
 {
-   bool valid_handle;
-
-   valid_handle = ion_handle_validate(client, handle);
-
-   if (!valid_handle) {
+   if (!ion_handle_validate(client, handle)) {
WARN(1, "%s: invalid handle passed to free.\n", __func__);
return;
}
-- 
2.1.4

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


[PATCH 1/2] staging: android: ion: Do not BUG on handle client mismatch

2016-08-22 Thread Johanna Abrahamsson
The ion_free() and ion_free_nolock() functions should not BUG on a
handle client mismatch. It is not necessary to explicitly check for that
mismatch when ion_handle_validate is used.

Signed-off-by: Johanna Abrahamsson 
---
 drivers/staging/android/ion/ion.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 291d5b8..d209bda 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -550,8 +550,6 @@ static void ion_free_nolock(struct ion_client *client,
 {
bool valid_handle;
 
-   BUG_ON(client != handle->client);
-
valid_handle = ion_handle_validate(client, handle);
 
if (!valid_handle) {
@@ -563,8 +561,6 @@ static void ion_free_nolock(struct ion_client *client,
 
 void ion_free(struct ion_client *client, struct ion_handle *handle)
 {
-   BUG_ON(client != handle->client);
-
mutex_lock(>lock);
ion_free_nolock(client, handle);
mutex_unlock(>lock);
-- 
2.1.4

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


[PATCH 0/2] staging: android: ion: cleanup of the ion_free functions

2016-08-22 Thread Johanna Abrahamsson
This is a small cleanup of the ion_free() and ion_free_nolock() methods. They 
are in a patchset because they depend lightly on each other, as in that patch 2 
won't apply due to changes in the context. Since this is my first patchset 
please let me know if I am doing it wrong.

Johanna Abrahamsson (2):
  staging: android: ion: Do not BUG on handle client mismatch
  staging: android: ion: Remove valid_handle variable in ion_free_nolock

 drivers/staging/android/ion/ion.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

-- 
2.1.4

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


[PATCH] staging: android: ion: Fix alignment

2016-08-22 Thread Johanna Abrahamsson
Alignment should match open parenthesis as per checkpatch.pl.

Signed-off-by: Johanna Abrahamsson 
---
 drivers/staging/android/ion/ion.c | 42 +++
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 88dd17e..291d5b8 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -174,10 +174,10 @@ static void ion_buffer_add(struct ion_device *dev,
 
 /* this function should only be called while dev->lock is held */
 static struct ion_buffer *ion_buffer_create(struct ion_heap *heap,
-struct ion_device *dev,
-unsigned long len,
-unsigned long align,
-unsigned long flags)
+   struct ion_device *dev,
+   unsigned long len,
+   unsigned long align,
+   unsigned long flags)
 {
struct ion_buffer *buffer;
struct sg_table *table;
@@ -331,7 +331,7 @@ static void ion_buffer_remove_from_handle(struct ion_buffer 
*buffer)
 }
 
 static struct ion_handle *ion_handle_create(struct ion_client *client,
-struct ion_buffer *buffer)
+   struct ion_buffer *buffer)
 {
struct ion_handle *handle;
 
@@ -421,7 +421,7 @@ static struct ion_handle *ion_handle_lookup(struct 
ion_client *client,
 }
 
 static struct ion_handle *ion_handle_get_by_id_nolock(struct ion_client 
*client,
-   int id)
+ int id)
 {
struct ion_handle *handle;
 
@@ -581,7 +581,7 @@ static void *ion_buffer_kmap_get(struct ion_buffer *buffer)
}
vaddr = buffer->heap->ops->map_kernel(buffer->heap, buffer);
if (WARN_ONCE(vaddr == NULL,
-   "heap->ops->map_kernel should return ERR_PTR on error"))
+ "heap->ops->map_kernel should return ERR_PTR on error"))
return ERR_PTR(-EINVAL);
if (IS_ERR(vaddr))
return vaddr;
@@ -750,7 +750,7 @@ static const struct file_operations debug_client_fops = {
 };
 
 static int ion_get_client_serial(const struct rb_root *root,
-   const unsigned char *name)
+const unsigned char *name)
 {
int serial = -1;
struct rb_node *node;
@@ -839,7 +839,7 @@ struct ion_client *ion_client_create(struct ion_device *dev,
 
path = dentry_path(dev->clients_debug_root, buf, 256);
pr_err("Failed to create client debugfs at %s/%s\n",
-   path, client->display_name);
+  path, client->display_name);
}
 
up_write(>lock);
@@ -907,7 +907,7 @@ static void ion_unmap_dma_buf(struct dma_buf_attachment 
*attachment,
 }
 
 void ion_pages_sync_for_device(struct device *dev, struct page *page,
-   size_t size, enum dma_data_direction dir)
+  size_t size, enum dma_data_direction dir)
 {
struct scatterlist sg;
 
@@ -947,7 +947,7 @@ static void ion_buffer_sync_for_device(struct ion_buffer 
*buffer,
 
if (ion_buffer_page_is_dirty(page))
ion_pages_sync_for_device(dev, ion_buffer_page(page),
-   PAGE_SIZE, dir);
+ PAGE_SIZE, dir);
 
ion_buffer_page_clean(buffer->pages + i);
}
@@ -1025,7 +1025,7 @@ static int ion_mmap(struct dma_buf *dmabuf, struct 
vm_area_struct *vma)
 
if (!buffer->heap->ops->map_user) {
pr_err("%s: this heap does not define a method for mapping to 
userspace\n",
-   __func__);
+  __func__);
return -EINVAL;
}
 
@@ -1116,7 +1116,7 @@ static struct dma_buf_ops dma_buf_ops = {
 };
 
 struct dma_buf *ion_share_dma_buf(struct ion_client *client,
-   struct ion_handle *handle)
+ struct ion_handle *handle)
 {
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
struct ion_buffer *buffer;
@@ -1291,9 +1291,9 @@ static long ion_ioctl(struct file *filp, unsigned int 
cmd, unsigned long arg)
struct ion_handle *handle;
 
handle = ion_alloc(client, data.allocation.len,
-   data.allocation.align,
-   data.allocation.heap_id_mask,
-   data.allocation.flags);
+  

Re: [PATCH 3/3] staging: most: aim-cdev: relocate call to ida_init()

2016-08-22 Thread Greg KH
On Mon, Aug 22, 2016 at 10:58:07AM +0200, Christian Gromm wrote:
> On Sun, 21 Aug 2016 16:50:20 +0200
> Greg KH  wrote:
> 
> > On Fri, Aug 19, 2016 at 01:09:35PM +0200, Christian Gromm wrote:
> > > This patch moves the initialization of the idr structure towards the end
> > > of the module's init routine. This keeps the code compact and eliminates
> > > the need of having to call ida_destroy() in case the function exits with
> > > an exception.
> > > 
> > > Signed-off-by: Christian Gromm 
> > > ---
> > >  drivers/staging/most/aim-cdev/cdev.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/staging/most/aim-cdev/cdev.c 
> > > b/drivers/staging/most/aim-cdev/cdev.c
> > > index db6f458..3864009 100644
> > > --- a/drivers/staging/most/aim-cdev/cdev.c
> > > +++ b/drivers/staging/most/aim-cdev/cdev.c
> > > @@ -505,7 +505,6 @@ static int __init mod_init(void)
> > >  
> > >   INIT_LIST_HEAD(_list);
> > >   spin_lock_init(_list_lock);
> > > - ida_init(_id);
> > >  
> > >   err = alloc_chrdev_region(_devno, 0, 50, "cdev");
> > >   if (err < 0)
> > > @@ -521,6 +520,7 @@ static int __init mod_init(void)
> > >   err = most_register_aim(_aim);
> > >   if (err)
> > >   goto dest_class;
> > > + ida_init(_id);
> > 
> > But can't the minor_id be used before this call?  most_register_aim()
> > could call into a driver and have a cdev be wanted, right?
> 
> No. After calling most_register_aim() the device appears in sysfs. Then
> the user needs to establish a link to a certain channel of the hardware
> by writing to the sysfs attribute add_link. And this is when minor_id is
> being used to create a new device that will show up in /dev.
> 
> See store_add_link() function of the core module.

Ok, I'll trust you :)

Can you resend this, it's gone from my queue now...

thanks,

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


Re: [PATCH] staging/lustre: avoid zero buf for the first time

2016-08-22 Thread Greg Kroah-Hartman
On Mon, Aug 22, 2016 at 04:46:04PM +0800, Shawn Lin wrote:
> We only need to zero it when repeating in order to
> avoid old garbage. Let's improve it by moving this
> before we repeat the calculation to save some cpu
> cycle.
> 
> Signed-off-by: Shawn Lin 

Have you noticed a change with this in a benchmark?

If not, is it really worth it?

I need an ack from the lustre developers before taking patches like
this...

thanks,

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


Re: [staging:staging-testing 201/347] drivers/staging/lustre/lustre/mdc/mdc_request.c:1243:32: error: 'dp' undeclared

2016-08-22 Thread Greg Kroah-Hartman
On Mon, Aug 22, 2016 at 03:15:23PM +0800, kbuild test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
> staging-testing
> head:   f5a9a15f8fd4168e415e94f5dce367f3cef08e03
> commit: 4f76f0ec093c2f9ef049495c78d486bfb48e4de0 [201/347] staging: lustre: 
> llite: move dir cache to MDC layer
> config: alpha-allyesconfig (attached as .config)
> compiler: alpha-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 4f76f0ec093c2f9ef049495c78d486bfb48e4de0
> # save the attached .config to linux build tree
> make.cross ARCH=alpha 

Odd, I can't duplicate this on x86, what's so strange about alpha?

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


Re: [PATCH 3/3] staging: most: aim-cdev: relocate call to ida_init()

2016-08-22 Thread Christian Gromm
On Sun, 21 Aug 2016 16:50:20 +0200
Greg KH  wrote:

> On Fri, Aug 19, 2016 at 01:09:35PM +0200, Christian Gromm wrote:
> > This patch moves the initialization of the idr structure towards the end
> > of the module's init routine. This keeps the code compact and eliminates
> > the need of having to call ida_destroy() in case the function exits with
> > an exception.
> > 
> > Signed-off-by: Christian Gromm 
> > ---
> >  drivers/staging/most/aim-cdev/cdev.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/staging/most/aim-cdev/cdev.c 
> > b/drivers/staging/most/aim-cdev/cdev.c
> > index db6f458..3864009 100644
> > --- a/drivers/staging/most/aim-cdev/cdev.c
> > +++ b/drivers/staging/most/aim-cdev/cdev.c
> > @@ -505,7 +505,6 @@ static int __init mod_init(void)
> >  
> > INIT_LIST_HEAD(_list);
> > spin_lock_init(_list_lock);
> > -   ida_init(_id);
> >  
> > err = alloc_chrdev_region(_devno, 0, 50, "cdev");
> > if (err < 0)
> > @@ -521,6 +520,7 @@ static int __init mod_init(void)
> > err = most_register_aim(_aim);
> > if (err)
> > goto dest_class;
> > +   ida_init(_id);
> 
> But can't the minor_id be used before this call?  most_register_aim()
> could call into a driver and have a cdev be wanted, right?

No. After calling most_register_aim() the device appears in sysfs. Then
the user needs to establish a link to a certain channel of the hardware
by writing to the sysfs attribute add_link. And this is when minor_id is
being used to create a new device that will show up in /dev.

See store_add_link() function of the core module.


regards,
Chris

> 
> thanks,
> 
> greg k-h

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


[PATCH] staging/lustre: avoid zero buf for the first time

2016-08-22 Thread Shawn Lin
We only need to zero it when repeating in order to
avoid old garbage. Let's improve it by moving this
before we repeat the calculation to save some cpu
cycle.

Signed-off-by: Shawn Lin 
---

 drivers/staging/lustre/lustre/obdclass/llog.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/llog.c 
b/drivers/staging/lustre/lustre/obdclass/llog.c
index 1784ca0..923061f 100644
--- a/drivers/staging/lustre/lustre/obdclass/llog.c
+++ b/drivers/staging/lustre/lustre/obdclass/llog.c
@@ -248,8 +248,6 @@ repeat:
CDEBUG(D_OTHER, "index: %d last_index %d\n",
   index, last_index);
 
-   /* get the buf with our target record; avoid old garbage */
-   memset(buf, 0, LLOG_CHUNK_SIZE);
last_offset = cur_offset;
rc = llog_next_block(lpi->lpi_env, loghandle, _index,
 index, _offset, buf, LLOG_CHUNK_SIZE);
@@ -275,8 +273,11 @@ repeat:
if (rec->lrh_index == 0) {
/* probably another rec just got added? */
rc = 0;
-   if (index <= loghandle->lgh_last_idx)
+   if (index <= loghandle->lgh_last_idx) {
+   /* avoid old garbage */
+   memset(buf, 0, LLOG_CHUNK_SIZE);
goto repeat;
+   }
goto out; /* no more records */
}
if (rec->lrh_len == 0 ||
-- 
2.3.7


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


[staging:staging-testing 168/347] arch/frv/include/asm/atomic.h:186:1: note: in expansion of macro 'ATOMIC_OP'

2016-08-22 Thread kbuild test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
staging-testing
head:   f5a9a15f8fd4168e415e94f5dce367f3cef08e03
commit: d806f30e639b0ff5abeb012b08932691be795342 [168/347] staging: lustre: 
osc: revise unstable pages accounting
config: frv-allmodconfig (attached as .config)
compiler: frv-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout d806f30e639b0ff5abeb012b08932691be795342
# save the attached .config to linux build tree
make.cross ARCH=frv 

All warnings (new ones prefixed by >>):

   In file included from arch/frv/include/asm/bitops.h:28:0,
from include/linux/bitops.h:36,
from 
drivers/staging/lustre/lustre/osc/../../include/linux/libcfs/linux/libcfs.h:40,
from 
drivers/staging/lustre/lustre/osc/../../include/linux/libcfs/libcfs.h:36,
from drivers/staging/lustre/lustre/osc/osc_cl_internal.h:45,
from drivers/staging/lustre/lustre/osc/osc_page.c:40:
   drivers/staging/lustre/lustre/osc/osc_page.c: In function 
'osc_dec_unstable_pages':
   arch/frv/include/asm/atomic.h:171:2: warning: array subscript is above array 
bounds [-Warray-bounds]
 (void)__atomic32_fetch_##op(i, >counter);   \
 ^
>> arch/frv/include/asm/atomic.h:186:1: note: in expansion of macro 'ATOMIC_OP'
ATOMIC_OP(add)
^
   arch/frv/include/asm/atomic.h:171:2: warning: array subscript is above array 
bounds [-Warray-bounds]
 (void)__atomic32_fetch_##op(i, >counter);   \
 ^
>> arch/frv/include/asm/atomic.h:186:1: note: in expansion of macro 'ATOMIC_OP'
ATOMIC_OP(add)
^
   drivers/staging/lustre/lustre/osc/osc_page.c: In function 
'osc_inc_unstable_pages':
   arch/frv/include/asm/atomic.h:171:2: warning: array subscript is above array 
bounds [-Warray-bounds]
 (void)__atomic32_fetch_##op(i, >counter);   \
 ^
>> arch/frv/include/asm/atomic.h:186:1: note: in expansion of macro 'ATOMIC_OP'
ATOMIC_OP(add)
^
   arch/frv/include/asm/atomic.h:171:2: warning: array subscript is above array 
bounds [-Warray-bounds]
 (void)__atomic32_fetch_##op(i, >counter);   \
 ^
>> arch/frv/include/asm/atomic.h:186:1: note: in expansion of macro 'ATOMIC_OP'
ATOMIC_OP(add)
^
   /tmp/ccddFWC4.s: Assembler messages:
   /tmp/ccddFWC4.s:28583: Error: symbol `.LSLT0' is already defined
   /tmp/ccddFWC4.s:28586: Error: symbol `.LASLTP0' is already defined
   /tmp/ccddFWC4.s:28985: Error: symbol `.LELTP0' is already defined
   /tmp/ccddFWC4.s:28986: Error: symbol `.LELT0' is already defined

vim +/ATOMIC_OP +186 arch/frv/include/asm/atomic.h

d9c73028 Peter Zijlstra 2016-04-18  165  static inline int 
atomic_fetch_##op(int i, atomic_t *v)\
d9c73028 Peter Zijlstra 2016-04-18  166  {  
\
d9c73028 Peter Zijlstra 2016-04-18  167 return __atomic32_fetch_##op(i, 
>counter);   \
d9c73028 Peter Zijlstra 2016-04-18  168  }  
\
b0d8003e Peter Zijlstra 2015-04-24  169  static inline void atomic_##op(int i, 
atomic_t *v) \
b0d8003e Peter Zijlstra 2015-04-24  170  {  
\
b0d8003e Peter Zijlstra 2015-04-24 @171 (void)__atomic32_fetch_##op(i, 
>counter);\
b0d8003e Peter Zijlstra 2015-04-24  172  }  
\
b0d8003e Peter Zijlstra 2015-04-24  173 
\
d9c73028 Peter Zijlstra 2016-04-18  174  static inline long long 
atomic64_fetch_##op(long long i, atomic64_t *v)\
d9c73028 Peter Zijlstra 2016-04-18  175  {  
\
d9c73028 Peter Zijlstra 2016-04-18  176 return __atomic64_fetch_##op(i, 
>counter);   \
d9c73028 Peter Zijlstra 2016-04-18  177  }  
\
b0d8003e Peter Zijlstra 2015-04-24  178  static inline void atomic64_##op(long 
long i, atomic64_t *v)   \
b0d8003e Peter Zijlstra 2015-04-24  179  {  
\
b0d8003e Peter Zijlstra 2015-04-24  180 (void)__atomic64_fetch_##op(i, 
>counter);\
b0d8003e Peter Zijlstra 2015-04-24  181  }
b0d8003e Peter Zijlstra 2015-04-24  182  
b0d8003e Peter Zijlstra 2015-04-24  183  ATOMIC_OP(or)
b0d8003e Peter Zijlstra 2015-04-24  184  ATOMIC_OP(and)
b0d8003e Peter Zijlstra 2015-04-24  185  ATOMIC_OP(xor)
d9c73028 Peter Zijlstra 2016-04-18 @186  ATOMIC_OP(add)
d9c73028 Peter Zijlstra 2016-04-18  187  ATOMIC_OP(sub)

Re: [PATCH 3/3] drivers: Add visorbus to the drivers/virt directory

2016-08-22 Thread 'Greg KH'
On Mon, Aug 22, 2016 at 02:48:18AM +, Sell, Timothy C wrote:
> > -Original Message-
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Sunday, August 21, 2016 2:05 PM
> > To: Kershner, David A 
> > Cc: cor...@lwn.net; t...@linutronix.de; mi...@redhat.com;
> > h...@zytor.com; Arfvidson, Erik ; Sell, Timothy
> > C ; hof...@osadl.org; dzic...@redhat.com;
> > jes.soren...@redhat.com; Curtin, Alexander Paul
> > ; janani.rvchn...@gmail.com;
> > sudipm.mukher...@gmail.com; pra...@redhat.com; Binder, David Anthony
> > ; nhor...@redhat.com;
> > dan.j.willi...@intel.com; linux-ker...@vger.kernel.org; linux-
> > d...@vger.kernel.org; driverdev-devel@linuxdriverproject.org; *S-Par-
> > Maintainer 
> > Subject: Re: [PATCH 3/3] drivers: Add visorbus to the drivers/virt directory
> > 
> > On Fri, Jun 10, 2016 at 11:23:56PM -0400, David Kershner wrote:
> > > visorbus is currently located at drivers/staging/visorbus,
> > > this patch moves it to drivers/virt.
> > >
> > > Signed-off-by: David Kershner 
> > > Reviewed-by: Tim Sell 
> > > ---
> > >  drivers/staging/unisys/Kconfig| 
> > > 3 +--
> > >  drivers/staging/unisys/Makefile   | 
> > > 1 -
> > >  drivers/virt/Kconfig  | 
> > > 2 ++
> > >  drivers/virt/Makefile | 
> > > 1 +
> > >  drivers/{staging/unisys => virt}/visorbus/Kconfig | 0
> > >  drivers/{staging/unisys => virt}/visorbus/Makefile| 0
> > >  drivers/{staging/unisys => virt}/visorbus/controlvmchannel.h  | 0
> > >  drivers/{staging/unisys => virt}/visorbus/controlvmcompletionstatus.h | 0
> > >  drivers/{staging/unisys => virt}/visorbus/iovmcall_gnuc.h | 0
> > >  drivers/{staging/unisys => virt}/visorbus/vbuschannel.h   | 0
> > >  drivers/{staging/unisys => virt}/visorbus/vbusdeviceinfo.h| 0
> > >  drivers/{staging/unisys => virt}/visorbus/vbushelper.h| 0
> > >  drivers/{staging/unisys => virt}/visorbus/visorbus_main.c | 0
> > >  drivers/{staging/unisys => virt}/visorbus/visorbus_private.h  | 0
> > >  drivers/{staging/unisys => virt}/visorbus/visorchannel.c  | 0
> > >  drivers/{staging/unisys => virt}/visorbus/visorchipset.c  | 0
> > 
> > I picked one random file here, this last one, and found a number of
> > "odd" things in it.
> > 
> > So, given that I can't really comment on the patch itself, I'm going to
> > include the file below, quote it, and then provide some comments, ok?
> > > /* visorchipset_main.c
> > > ...
> > > static void
> > > controlvm_init_response(struct controlvm_message *msg,
> > >   struct controlvm_message_header *msg_hdr, int response)
> > > {
> > >   memset(msg, 0, sizeof(struct controlvm_message));
> > >   memcpy(>hdr, msg_hdr, sizeof(struct controlvm_message_header));
> > >   msg->hdr.payload_bytes = 0;
> > >   msg->hdr.payload_vm_offset = 0;
> > >   msg->hdr.payload_max_bytes = 0;
> > >   if (response < 0) {
> > >   msg->hdr.flags.failed = 1;
> > >   msg->hdr.completion_status = (u32)(-response);
> > >   }
> > > }
> > > 
> > > static void
> > > Billy(struct controlvm_message_header *msg_hdr, int response)
> > 
> > Not John?  Bob?  Sally?  Alice?  Bernise?  Jean?  Molly?
> 
> Huh? What version of source code are you looking at??
> 
> The file being moved by this patch should be
> drivers/staging/unisys/visorbus/visorchipset.c in your staging-next branch  
> (https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/tree/drivers/staging/unisys/visorbus/visorchipset.c?h=staging-next).
> If you look there, you will NOT find "Billy()", but instead 
> "controlvm_respond()", i.e.:
> 
> static void
> controlvm_init_response(struct controlvm_message *msg,
>   struct controlvm_message_header *msg_hdr, int response)


oh that's funny, I have no idea what happened here, perhaps when I
copied the file into the original email?  Strange things happen while on
planes...

Anyway, ok, one comment addressed, great!  Now about the many many
others?

thanks,

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


[staging:staging-testing 201/347] drivers/staging/lustre/lustre/mdc/mdc_request.c:1243:32: error: 'dp' undeclared

2016-08-22 Thread kbuild test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
staging-testing
head:   f5a9a15f8fd4168e415e94f5dce367f3cef08e03
commit: 4f76f0ec093c2f9ef049495c78d486bfb48e4de0 [201/347] staging: lustre: 
llite: move dir cache to MDC layer
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 4f76f0ec093c2f9ef049495c78d486bfb48e4de0
# save the attached .config to linux build tree
make.cross ARCH=alpha 

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/byteorder/little_endian.h:4:0,
from arch/alpha/include/uapi/asm/byteorder.h:4,
from include/asm-generic/bitops/le.h:5,
from arch/alpha/include/asm/bitops.h:454,
from include/linux/bitops.h:36,
from include/linux/kernel.h:10,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/staging/lustre/lustre/mdc/mdc_request.c:35:
   drivers/staging/lustre/lustre/mdc/mdc_request.c: In function 
'mdc_adjust_dirpages':
>> drivers/staging/lustre/lustre/mdc/mdc_request.c:1243:32: error: 'dp' 
>> undeclared (first use in this function)
  __u64 hash_end = le64_to_cpu(dp->ldp_hash_end);
   ^
   include/uapi/linux/byteorder/little_endian.h:31:51: note: in definition of 
macro '__le64_to_cpu'
#define __le64_to_cpu(x) ((__force __u64)(__le64)(x))
  ^
>> drivers/staging/lustre/lustre/mdc/mdc_request.c:1243:20: note: in expansion 
>> of macro 'le64_to_cpu'
  __u64 hash_end = le64_to_cpu(dp->ldp_hash_end);
   ^
   drivers/staging/lustre/lustre/mdc/mdc_request.c:1243:32: note: each 
undeclared identifier is reported only once for each function it appears in
  __u64 hash_end = le64_to_cpu(dp->ldp_hash_end);
   ^
   include/uapi/linux/byteorder/little_endian.h:31:51: note: in definition of 
macro '__le64_to_cpu'
#define __le64_to_cpu(x) ((__force __u64)(__le64)(x))
  ^
>> drivers/staging/lustre/lustre/mdc/mdc_request.c:1243:20: note: in expansion 
>> of macro 'le64_to_cpu'
  __u64 hash_end = le64_to_cpu(dp->ldp_hash_end);
   ^

vim +/dp +1243 drivers/staging/lustre/lustre/mdc/mdc_request.c

  1237  #if PAGE_SIZE > LU_PAGE_SIZE
  1238  static void mdc_adjust_dirpages(struct page **pages, int cfs_pgs, int 
lu_pgs)
  1239  {
  1240  int i;
  1241  
  1242  for (i = 0; i < cfs_pgs; i++) {
> 1243  __u64 hash_end = le64_to_cpu(dp->ldp_hash_end);
  1244  __u32 flags = le32_to_cpu(dp->ldp_flags);
  1245  struct lu_dirpage *dp = kmap(pages[i]);
  1246  struct lu_dirpage *first = dp;

---
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