date:20161205

VERTRAULICH

2016-12-05 Thread ANWALT MORATO ORTEGA

Mein lieber Freund,

Ich mцchte mich erstmals gerne vorstellen.  Mein Name ist Herr Morato Ortega 
die persцnliche Investment Berater und Vermцgensverwalterin meines verstorbenen 
Mandanten, der ihre familienname tragt. Er war als privater Geschдftsmann im 
internationalen Bereich tдtig. Im Jahr 2008 starb mein Mandant an einen 
schweren Herzinfarkt. Mein Mandant war ledig und kinderlos.

Er hinterlieЯ ein Vermцgen im Wert von Ђ10.500.000 (Zehn Millionen 
fьnfhunderttausend Euro), das sich in einer Bank in Spanien befindet.  Die Bank 
lieЯ mir zukommen, dass ich einen Erbberechtigen, Begьnstigten vorstellen muss.

Nach mehreren Recherchen erhielt ich keine weiteren hilfreichen Informationen, 
ьber die  Verwandten meines verstorbenen Mandanten. Aus diesem Grund schrieb 
ich Sie an, da Sie den gleichen Nachnamen haben. Ich benцtige Ihre Zustimmung 
und Ihre Kooperation um Sie als den Begьnstigten vorzustellen. Alle meine 
Bemьhungen Verwandte meines verstorbenen Mandanten zu finden, waren erfolglos. 
Infolgedessen wьrde ich vorschlagen das Vermцgen aufzuteilen, Sie erhalten 45% 
Prozent des Anteils und  45% Prozent wьrde mir dann zustehen. 10% Prozent 
werden an Gemeinnьtzige Organisationen gespendet.

Alle notwendigen Dokumente beinhalten sinngemдЯ auch das Ursprungszeugnis, um 
demnach  Fragen von der zustдndigen Bank zu vermeiden. Die beantragten 
Dokumente, die Sie fьr das Verfahren benцtigen, sind legal und beglaubigt. Das 
Vermцgen enthдlt kein kriminellen Ursprung. Das Verfahren wird einwandfrei ohne 
Komplikationen erfolgen,  die Geldьberweisung wird rechts gemдЯ abgeschlossen. 
Alles was ich von Ihnen benцtige  ist Ihr Vertrauen und eine gute 
Zusammenarbeit.

Kontaktieren Sie mich bitte unter  meine private E-Mail 
rod.ort...@consultant.com  .Die geplante Transaktion wird  durch legale 
Rechtsmitteln fьr Ihren rechtlichen Schutz gefьhrt.

Mit freundlichen Grussen
Dipl.finanzfachanwalt 
Abogado Morato Ortega
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/1] staging: android: ashmem: convert range macros to inlines and clean-up

2016-12-05 Thread Greg Kroah-Hartman

On Mon, Dec 05, 2016 at 08:01:35PM +, Guillaume Tucker wrote:
> On 12/05/16 18:08, Greg Kroah-Hartman wrote:
> > On Mon, Dec 05, 2016 at 05:34:15PM +, Guillaume Tucker wrote:
> >> Convert ashmem_range related macros to inline functions to fix
> >> checkpatch errors.  Clean up the code in related existing inline
> >> functions.
> > 
> > How about breaking this up into two different patches, one for the
> > inlines, and one to fix up the existing inline functions for coding
> > style issues?
> > 
> > thanks,
> > 
> > greg k-h
> 
> Sure, thanks.  I've sent a v2.
> 
> (and sorry the series still doesn't seem to be treated as a thread in
> spite of the In-Reply-To: and References: headers being there...)

They are there, but they are incorrect, are you using git send-email to
set them, or are you trying to do it by hand?

thanks,

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

Re: [PATCH 10/14] rtlwifi: Add BTC_TRACE_STRING to new btcoex

2016-12-05 Thread Greg KH

On Mon, Dec 05, 2016 at 04:34:08PM -0600, Larry Finger wrote:
> On 12/05/2016 03:34 PM, Dan Carpenter wrote:
> > On Thu, Dec 01, 2016 at 07:48:29PM -0600, Larry Finger wrote:
> > > --- 
> > > wireless-drivers-next.orig/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
> > > +++ 
> > > wireless-drivers-next/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
> > > @@ -27,6 +27,29 @@
> > > 
> > >  #include "../wifi.h"
> > > 
> > > +#ifdef CONFIG_RTLWIFI_DEBUG
> > > +
> > > +#define BTC_SPRINTF(ptr, ...)snprintf(ptr, ##__VA_ARGS__)
> > > +#define BTC_TRACE(fmt)   \
> > > +do { \
> > > + struct rtl_priv *rtlpriv = gl_bt_coexist.adapter;   \
> > > + if (!rtlpriv)   \
> > > + break;  \
> > > + RT_TRACE_STRING(rtlpriv, COMP_COEX, DBG_LOUD, fmt); \
> > > +} while (0)
> > > +
> > 
> > This sort of macro is exactly when the rtl drivers spent so long in
> > staging...  Subsystems should not invent their own tracing but in
> > particular these macros are so very very ugly.
> > 
> > It's just super frustrating to even look at this...
> > 
> > There are a lot of staging drivers I feel good about when they leave.
> > The HyperV drivers.  The IIO stuff.  A lot of the media stuff and
> > generally the media tree is getting better and better.  I like comedi
> > and unisys, those are in staging, but they are great and could move out
> > any time as far as I'm concerned.
> > 
> > But this patch just makes me super discouraged.  What are we doing???
> 
> Dan,
> 
> It would not matter to me if these drivers got moved to staging, but there
> are a lot of users whose distros do not build staging drivers that would be
> very unhappy.
> 
> Can you point me to a driver with a better way to conditionally dump a
> debugging string to the logs?

Just use 'dev_dbg()', or 'pr_debug()' if you don't have a device pointer
(hint, all drivers should have that pointer).  That can be turned on or
off by a user dynamically as the kernel runs.  No need to invent fancy
custom macros for things we have already for many many years.

thanks,

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

RE: [PATCH] pci-hyperv: use kmalloc to allocate hypercall params buffer

2016-12-05 Thread Long Li



> -Original Message-
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Monday, December 5, 2016 8:53 AM
> To: Long Li 
> Cc: KY Srinivasan ; Haiyang Zhang
> ; Bjorn Helgaas ;
> de...@linuxdriverproject.org; linux-ker...@vger.kernel.org; linux-
> p...@vger.kernel.org
> Subject: Re: [PATCH] pci-hyperv: use kmalloc to allocate hypercall params
> buffer
> 
> On Tue,  8 Nov 2016 14:04:38 -0800
> Long Li  wrote:
> 
> > +   spin_lock_irqsave(>retarget_msi_interrupt_lock, flags);
> > +
> > +   params = >retarget_msi_interrupt_params;
> > +   memset(params, 0, sizeof(*params));
> > +   params->partition_id = HV_PARTITION_ID_SELF;
> > +   params->source = 1; /* MSI(-X) */
> > +   params->address = msi_desc->msg.address_lo;
> > +   params->data = msi_desc->msg.data;
> > +   params->device_id = (hbus->hdev->dev_instance.b[5] << 24) |
> >(hbus->hdev->dev_instance.b[4] << 16) |
> >(hbus->hdev->dev_instance.b[7] << 8) |
> >(hbus->hdev->dev_instance.b[6] & 0xf8) |
> >PCI_FUNC(pdev->devfn);
> > -   params.vector = cfg->vector;
> > +   params->vector = cfg->vector;
> >
> > for_each_cpu_and(cpu, dest, cpu_online_mask)
> > -   params.vp_mask |= (1ULL <<
> vmbus_cpu_number_to_vp_number(cpu));
> > +   params->vp_mask |= (1ULL <<
> vmbus_cpu_number_to_vp_number(cpu));
> > +
> > +   hv_do_hypercall(HVCALL_RETARGET_INTERRUPT, params, NULL);
> >
> > -   hv_do_hypercall(HVCALL_RETARGET_INTERRUPT, , NULL);
> > +   spin_unlock_irqrestore(>retarget_msi_interrupt_lock, flags);
> 
> It looks like the additional locking here is being overly paranoid.
> The caller is already holding the irq descriptor lock. Look at fixup_irqs.

You are right. On my test machine, there are two possible places calling 
hv_irq_unmask(): request _irq() and handle_edge_irq(). They both have 
desc->lock held when calling .irq_unmask on the chip. A review of the IRQ code 
shows that desc->lock is always held while calling chip->irq_unmask().

Since the lock doesn't do any harm and it is not on performance code path, we 
can remove the lock in the upcoming patches.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 12/19] staging: iio: isl29028: fix comparison between signed and unsigned integers

2016-12-05 Thread Brian Masney

On Mon, Dec 05, 2016 at 11:53:39PM +0300, Dan Carpenter wrote:
> On Sat, Dec 03, 2016 at 09:19:36PM -0500, Brian Masney wrote:
> > Fixed warning found by make W=2 to reduce the amount of build noise:
> > 
> > warning: comparison between signed and unsigned integer expressions
> > [-Wsign-compare]
> 
> Ugh...  Please don't do work arounds for nonsense warnings.  W=2 is so
> stupid.  Better to just grep -v this warning instead of trying to please
> a broken static analysis.  Warnings like this are why it's disabled by
> default.

Hi Dan,
   I would normally agree, however there could be a case where this
warning flags a legitimate issue. It is obviously not an issue in this
case. Since I'm already working on cleaning up this driver to move it
out of staging, I figured that I would make sure that it builds cleanly
with W=2. This was the only warning found in that driver. The
change is harmless in my opinion and it may eliminate a nonsense warning
for someone else down the road when doing security audits.

   This driver doesn't need much to move it out of staging. Most of the
patches in this series were trivial cleanups and not interesting at all.
Since I already have one of these devices, I figured that I'd do the
grunt work to get it out of staging. My goal with the upcoming final
patch that moves it out of staging is to reduce the amount of code churn
in the driver once it graduates from staging.

Brian

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

RE: [PATCH] pci-hyperv: use kmalloc to allocate hypercall params buffer

2016-12-05 Thread Long Li

> -Original Message-
> From: KY Srinivasan
> Sent: Monday, December 5, 2016 1:23 PM
> To: Cathy Avery ; Bjorn Helgaas
> ; Long Li 
> Cc: de...@linuxdriverproject.org
> Subject: RE: [PATCH] pci-hyperv: use kmalloc to allocate hypercall params
> buffer
> 
> 
> 
> > -Original Message-
> > From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On
> > Behalf Of Cathy Avery
> > Sent: Monday, December 5, 2016 4:54 AM
> > To: Bjorn Helgaas ; Long Li 
> > Cc: de...@linuxdriverproject.org
> > Subject: Re: [PATCH] pci-hyperv: use kmalloc to allocate hypercall
> > params buffer
> >
> > Hi,
> >
> > Is the double semicolon a typo?
> 
> Yes; it is a typo.

I'll fix this.

> 
> K. Y
> >
> > Thanks,
> >
> > Cathy
> >
> > diff --git a/drivers/pci/host/pci-hyperv.c
> > b/drivers/pci/host/pci-hyperv.c index 763ff87..ca553df 100644
> > --- a/drivers/pci/host/pci-hyperv.c
> > +++ b/drivers/pci/host/pci-hyperv.c
> > @@ -378,6 +378,8 @@ struct hv_pcibus_device {
> > struct msi_domain_info msi_info;
> > struct msi_controller msi_chip;
> > struct irq_domain *irq_domain;
> > +   struct retarget_msi_interrupt retarget_msi_interrupt_params;
> > +   spinlock_t retarget_msi_interrupt_lock;;
> >   };
> >
> >
> >
> > On 11/29/2016 06:25 PM, Bjorn Helgaas wrote:
> > > On Tue, Nov 08, 2016 at 02:04:38PM -0800, Long Li wrote:
> > >> From: Long Li 
> > >>
> > >> hv_do_hypercall assumes that we pass a segment from a physically
> > >> continuous buffer. Buffer allocated on the stack may not work if
> > >> CONFIG_VMAP_STACK=y is set.
> > >>
> > >> Change to use kmalloc to allocate this buffer.
> > >>
> > >> The v2 patch adds locking to access the pre-allocated buffer.
> > >>
> > >> Signed-off-by: Long Li 
> > >> Reported-by: Haiyang Zhang 
> > > Applied with KY's ack to pci/host-hv, thanks!
> > >
> > >> ---
> > >>   drivers/pci/host/pci-hyperv.c | 29 +++--
> > >>   1 file changed, 19 insertions(+), 10 deletions(-)
> > >>
> > >> diff --git a/drivers/pci/host/pci-hyperv.c
> > >> b/drivers/pci/host/pci-hyperv.c index 763ff87..ca553df 100644
> > >> --- a/drivers/pci/host/pci-hyperv.c
> > >> +++ b/drivers/pci/host/pci-hyperv.c
> > >> @@ -378,6 +378,8 @@ struct hv_pcibus_device {
> > >>  struct msi_domain_info msi_info;
> > >>  struct msi_controller msi_chip;
> > >>  struct irq_domain *irq_domain;
> > >> +struct retarget_msi_interrupt retarget_msi_interrupt_params;
> > >> +spinlock_t retarget_msi_interrupt_lock;;
> > >>   };
> > >>
> > >>   /*
> > >> @@ -774,34 +776,40 @@ 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);
> > >> -struct retarget_msi_interrupt params;
> > >> +struct retarget_msi_interrupt *params;
> > >>  struct hv_pcibus_device *hbus;
> > >>  struct cpumask *dest;
> > >>  struct pci_bus *pbus;
> > >>  struct pci_dev *pdev;
> > >>  int cpu;
> > >> +unsigned long flags;
> > >>
> > >>  dest = irq_data_get_affinity_mask(data);
> > >>  pdev = msi_desc_to_pci_dev(msi_desc);
> > >>  pbus = pdev->bus;
> > >>  hbus = container_of(pbus->sysdata, struct hv_pcibus_device,
> > sysdata);
> > >>
> > >> -memset(, 0, sizeof(params));
> > >> -params.partition_id = HV_PARTITION_ID_SELF;
> > >> -params.source = 1; /* MSI(-X) */
> > >> -params.address = msi_desc->msg.address_lo;
> > >> -params.data = msi_desc->msg.data;
> > >> -params.device_id = (hbus->hdev->dev_instance.b[5] << 24) |
> > >> +spin_lock_irqsave(>retarget_msi_interrupt_lock, flags);
> > >> +
> > >> +params = >retarget_msi_interrupt_params;
> > >> +memset(params, 0, sizeof(*params));
> > >> +params->partition_id = HV_PARTITION_ID_SELF;
> > >> +params->source = 1; /* MSI(-X) */
> > >> +params->address = msi_desc->msg.address_lo;
> > >> +params->data = msi_desc->msg.data;
> > >> +params->device_id = (hbus->hdev->dev_instance.b[5] << 24) |
> > >> (hbus->hdev->dev_instance.b[4] << 16) |
> > >> (hbus->hdev->dev_instance.b[7] << 8) |
> > >> (hbus->hdev->dev_instance.b[6] & 0xf8) |
> > >> PCI_FUNC(pdev->devfn);
> > >> -params.vector = cfg->vector;
> > >> +params->vector = cfg->vector;
> > >>
> > >>  for_each_cpu_and(cpu, dest, cpu_online_mask)
> > >> -params.vp_mask |= (1ULL <<
> > vmbus_cpu_number_to_vp_number(cpu));
> > >> +params->vp_mask |= (1ULL <<
> > vmbus_cpu_number_to_vp_number(cpu));
> > >> +
> > >> +

Re: [lustre-devel] [bug report] staging: add Lustre file system client support

2016-12-05 Thread Oleg Drokin


On Nov 23, 2016, at 7:29 AM, Dan Carpenter wrote:

> Hi Lustre Devs,
> 
> The patch d7e09d0397e8: "staging: add Lustre file system client
> support" from May 2, 2013, leads to the following static checker
> warning:
> 
>   drivers/staging/lustre/lnet/selftest/console.c:1336 lstcon_test_add()
>   error: 'paramlen' from user is not capped properly
> 
> The story here, is that "paramlen" is capped but only if "param" is
> non-NULL.  This causes a problem.
> 
> drivers/staging/lustre/lnet/selftest/console.c
>  1311  
>  1312  LIBCFS_ALLOC(test, offsetof(struct lstcon_test, 
> tes_param[paramlen]));
> 
> We don't know that paramlen is non-NULL here.  Because of integer
> overflows we could end up allocating less than intended.

I think this must be a false positive in this case?

Before calling this function we do:
LIBCFS_ALLOC(param, args->lstio_tes_param_len);

in lst_test_add_ioctl(), so it's not any bigger than 128k (or kmalloc will 
fail).
Even if kmalloc would allow more than 128k allocations,
offsetof(struct lstcon_test, tes_param[0]) is bound to be a lot smaller than
the baseline allocation address for kmalloc, and therefore integer overflow
cannot happen at all.

> 
>  1313  if (!test) {
>  1314  CERROR("Can't allocate test descriptor\n");
>  1315  rc = -ENOMEM;
>  1316  
>  1317  goto out;
>  1318  }
>  1319  
>  1320  test->tes_hdr.tsb_id = batch->bat_hdr.tsb_id;
> 
> Which will lead to memory corruption when we use "test".
> 
>  1321  test->tes_batch = batch;
>  1322  test->tes_type = type;
>  1323  test->tes_oneside = 0; /* TODO */
>  1324  test->tes_loop = loop;
>  1325  test->tes_concur = concur;
>  1326  test->tes_stop_onerr = 1; /* TODO */
>  1327  test->tes_span = span;
>  1328  test->tes_dist = dist;
>  1329  test->tes_cliidx = 0; /* just used for creating RPC */
>  1330  test->tes_src_grp = src_grp;
>  1331  test->tes_dst_grp = dst_grp;
>  1332  INIT_LIST_HEAD(>tes_trans_list);
>  1333  
>  1334  if (param) {
> 
> Smatch is not smart enough to trace the implication that "'param' is
> non-NULL, means that 'paramlen' has been verified" across a function
> boundary.  Storing that sort of information would really increase the
> hardware requirements for running Smatch so it's not something I have
> planned currently.
> 
>  1335  test->tes_paramlen = paramlen;
>  1336  memcpy(>tes_param[0], param, paramlen);
>  1337  }
>  1338  
> 
> regards,
> dan carpenter
> ___
> 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 04/22] staging: lustre: osc: handle osc eviction correctly

2016-12-05 Thread Oleg Drokin

On Dec 5, 2016, at 3:55 PM, Dan Carpenter wrote:

> On Fri, Dec 02, 2016 at 07:53:11PM -0500, James Simmons wrote:
>> @@ -3183,8 +3182,10 @@ static int discard_cb(const struct lu_env *env, 
>> struct cl_io *io,
>>  /* page is top page. */
>>  info->oti_next_index = osc_index(ops) + 1;
>>  if (cl_page_own(env, io, page) == 0) {
>> -KLASSERT(ergo(page->cp_type == CPT_CACHEABLE,
>> -  !PageDirty(cl_page_vmpage(page;
>> +if (!ergo(page->cp_type == CPT_CACHEABLE,
>> +  !PageDirty(cl_page_vmpage(page
>> +CL_PAGE_DEBUG(D_ERROR, env, page,
>> +  "discard dirty page?\n");
> 
> 
> I don't understand the point of the ergo macro.  There are way too many
> double negatives (some of them hidden for my small brain).  How is that
> simpler than just writing it out:
> 
>   if (page->cp_type == CPT_CACHEABLE &&
>   PageDirty(cl_page_vmpage(page))
>CL_PAGE_DEBUG(D_ERROR, env, page, "discard dirty page?\n");

I guess it makes it sound chic or something?
I am not a huge fan of it either, esp. in a case like this, though
it might be somewhat more convenient in assertions (where this is converted 
from).
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [lustre-devel] [PATCH] staging: lustre: Fix a spatch warning due to an assignment from kernel to user space

2016-12-05 Thread Oleg Drokin


On Dec 2, 2016, at 12:33 PM, Quentin Lambert wrote:

> lnet_ipif_enumerate was assigning a pointer from kernel space to user
> space. This patch uses copy_to_user to properly do that assignment.

I guess it's a false positive?

While lnet_sock_ioctl()->kernel_sock_unlocked_ioctl() does call into the
f_op->unlocked_ioctl() with a userspace argument, note that we have
set_fs(KERNEL_DS); in there, therefore allowig copy_from_user
and friends to work on kernel data too as if it was userspace.
(I know it's ugly and we need to find a better way of getting this data,
but at least it's not incorrect).

> 
> Signed-off-by: Quentin Lambert 
> ---
> shouldn't we be using ifc_req instead of ifc_buf?
> 
> drivers/staging/lustre/lnet/lnet/lib-socket.c |8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
> 
> --- a/drivers/staging/lustre/lnet/lnet/lib-socket.c
> +++ b/drivers/staging/lustre/lnet/lnet/lib-socket.c
> @@ -181,7 +181,13 @@ lnet_ipif_enumerate(char ***namesp)
>   goto out0;
>   }
> 
> - ifc.ifc_buf = (char *)ifr;
> + rc = copy_to_user(ifc.ifc_buf, (char *)ifr,
> +   nalloc * sizeof(*ifr));
> + if (rc) {
> + rc = -ENOMEM;
> + goto out1;
> + }
> +
>   ifc.ifc_len = nalloc * sizeof(*ifr);
> 
>   rc = lnet_sock_ioctl(SIOCGIFCONF, (unsigned long));
> ___
> 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] staging: lustre: Fix function declaration/definition mismatch

2016-12-05 Thread Oleg Drokin


On Dec 4, 2016, at 10:06 PM,  
 wrote:

> From: Sandeep Jain 
> 
> Fixes following Sparse errors.
> lprocfs_status.c:1568:5: error: symbol 'lprocfs_wr_root_squash'
> redeclared with different type...
> lprocfs_status.c:1632:5: error: symbol 'lprocfs_wr_nosquash_nids'
> redeclared with different type...
> 
> Signed-off-by: Sandeep Jain 

Acked-by: Oleg Drokin 

> ---
> drivers/staging/lustre/lustre/include/lprocfs_status.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/include/lprocfs_status.h 
> b/drivers/staging/lustre/lustre/include/lprocfs_status.h
> index cc0713e..b5c24ca 100644
> --- a/drivers/staging/lustre/lustre/include/lprocfs_status.h
> +++ b/drivers/staging/lustre/lustre/include/lprocfs_status.h
> @@ -701,9 +701,9 @@ static struct lustre_attr lustre_attr_##name = 
> __ATTR(name, mode, show, store)
> extern const struct sysfs_ops lustre_sysfs_ops;
> 
> struct root_squash_info;
> -int lprocfs_wr_root_squash(const char *buffer, unsigned long count,
> +int lprocfs_wr_root_squash(const char __user *buffer, unsigned long count,
>  struct root_squash_info *squash, char *name);
> -int lprocfs_wr_nosquash_nids(const char *buffer, unsigned long count,
> +int lprocfs_wr_nosquash_nids(const char __user *buffer, unsigned long count,
>struct root_squash_info *squash, char *name);
> 
> /* all quota proc functions */
> -- 
> 2.7.4

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

Re: [PATCH] staging: lustre: mgc: make llog_process_lock static

2016-12-05 Thread Oleg Drokin


On Dec 4, 2016, at 9:21 PM,  
 wrote:

> From: Sandeep Jain 
> 
> Fix following sparse warning.
> mgc_request.c:376:1:
> warning: symbol 'llog_process_lock' was not declared. Should it be static?
> 
> Signed-off-by: Sandeep Jain 

Acked-by: Oleg Drokin 

> ---
> drivers/staging/lustre/lustre/mgc/mgc_request.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c 
> b/drivers/staging/lustre/lustre/mgc/mgc_request.c
> index 23600fb..e98a2ce 100644
> --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c
> +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c
> @@ -373,7 +373,7 @@ static int config_log_add(struct obd_device *obd, char 
> *logname,
>   return rc;
> }
> 
> -DEFINE_MUTEX(llog_process_lock);
> +static DEFINE_MUTEX(llog_process_lock);
> 
> /** Stop watching for updates on this log.
>  */
> -- 
> 2.7.4

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

Re: [PATCH 1/1] staging: lustre: lnet: fix improper return value

2016-12-05 Thread Oleg Drokin


On Dec 3, 2016, at 7:52 AM, Pan Bian wrote:

> From: Pan Bian 
> 
> At the end of function lstcon_group_info(), "return 0" seems improper.
> It may be better to return the value of rc.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188811
> 
> Signed-off-by: Pan Bian 

Acked-by: Oleg Drokin 

> ---
> drivers/staging/lustre/lnet/selftest/console.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/lustre/lnet/selftest/console.c 
> b/drivers/staging/lustre/lnet/selftest/console.c
> index a0fcbf3..9a7c41a 100644
> --- a/drivers/staging/lustre/lnet/selftest/console.c
> +++ b/drivers/staging/lustre/lnet/selftest/console.c
> @@ -820,7 +820,7 @@
> 
>   lstcon_group_decref(grp);
> 
> - return 0;
> + return rc;
> }
> 
> static int
> -- 
> 1.9.1
> 

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

Re: [PATCH 10/14] rtlwifi: Add BTC_TRACE_STRING to new btcoex

2016-12-05 Thread Larry Finger


On 12/05/2016 03:34 PM, Dan Carpenter wrote:

On Thu, Dec 01, 2016 at 07:48:29PM -0600, Larry Finger wrote:

--- 
wireless-drivers-next.orig/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
+++ 
wireless-drivers-next/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
@@ -27,6 +27,29 @@

 #include   "../wifi.h"

+#ifdef CONFIG_RTLWIFI_DEBUG
+
+#define BTC_SPRINTF(ptr, ...)  snprintf(ptr, ##__VA_ARGS__)
+#define BTC_TRACE(fmt) \
+do {   \
+   struct rtl_priv *rtlpriv = gl_bt_coexist.adapter;   \
+   if (!rtlpriv)   \
+   break;  \
+   RT_TRACE_STRING(rtlpriv, COMP_COEX, DBG_LOUD, fmt); \
+} while (0)
+


This sort of macro is exactly when the rtl drivers spent so long in
staging...  Subsystems should not invent their own tracing but in
particular these macros are so very very ugly.

It's just super frustrating to even look at this...

There are a lot of staging drivers I feel good about when they leave.
The HyperV drivers.  The IIO stuff.  A lot of the media stuff and
generally the media tree is getting better and better.  I like comedi
and unisys, those are in staging, but they are great and could move out
any time as far as I'm concerned.

But this patch just makes me super discouraged.  What are we doing???


Dan,

It would not matter to me if these drivers got moved to staging, but there are a 
lot of users whose distros do not build staging drivers that would be very unhappy.


Can you point me to a driver with a better way to conditionally dump a debugging 
string to the logs?


Larry

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

[PATCH v4 net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver

2016-12-05 Thread Lino Sanfilippo

Add driver for Alacritech gigabit ethernet cards with SLIC (session-layer
interface control) technology. The driver provides basic support without
SLIC for the following devices:

- Mojave cards (single port PCI Gigabit) both copper and fiber
- Oasis cards (single and dual port PCI-x Gigabit) copper and fiber
- Kalahari cards (dual and quad port PCI-e Gigabit) copper and fiber

Signed-off-by: Lino Sanfilippo 
---
 drivers/net/ethernet/Kconfig  |1 +
 drivers/net/ethernet/Makefile |1 +
 drivers/net/ethernet/alacritech/Kconfig   |   28 +
 drivers/net/ethernet/alacritech/Makefile  |4 +
 drivers/net/ethernet/alacritech/slic.h|  575 +
 drivers/net/ethernet/alacritech/slicoss.c | 1882 +
 6 files changed, 2491 insertions(+)
 create mode 100644 drivers/net/ethernet/alacritech/Kconfig
 create mode 100644 drivers/net/ethernet/alacritech/Makefile
 create mode 100644 drivers/net/ethernet/alacritech/slic.h
 create mode 100644 drivers/net/ethernet/alacritech/slicoss.c

diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index 2ffd634..a4cc87fe 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -21,6 +21,7 @@ source "drivers/net/ethernet/3com/Kconfig"
 source "drivers/net/ethernet/adaptec/Kconfig"
 source "drivers/net/ethernet/aeroflex/Kconfig"
 source "drivers/net/ethernet/agere/Kconfig"
+source "drivers/net/ethernet/alacritech/Kconfig"
 source "drivers/net/ethernet/allwinner/Kconfig"
 source "drivers/net/ethernet/alteon/Kconfig"
 source "drivers/net/ethernet/altera/Kconfig"
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 1d349e9..b448027 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_NET_VENDOR_8390) += 8390/
 obj-$(CONFIG_NET_VENDOR_ADAPTEC) += adaptec/
 obj-$(CONFIG_GRETH) += aeroflex/
 obj-$(CONFIG_NET_VENDOR_AGERE) += agere/
+obj-$(CONFIG_NET_VENDOR_ALACRITECH) += alacritech/
 obj-$(CONFIG_NET_VENDOR_ALLWINNER) += allwinner/
 obj-$(CONFIG_NET_VENDOR_ALTEON) += alteon/
 obj-$(CONFIG_ALTERA_TSE) += altera/
diff --git a/drivers/net/ethernet/alacritech/Kconfig 
b/drivers/net/ethernet/alacritech/Kconfig
new file mode 100644
index 000..09496e1
--- /dev/null
+++ b/drivers/net/ethernet/alacritech/Kconfig
@@ -0,0 +1,28 @@
+config NET_VENDOR_ALACRITECH
+   bool "Alacritech devices"
+   default y
+   ---help---
+ If you have a network (Ethernet) card belonging to this class, say Y.
+
+ Note that the answer to this question doesn't directly affect the
+ kernel: saying N will just cause the configurator to skip all the
+ questions about Alacritech devices. If you say Y, you will be asked
+ for your specific device in the following questions.
+
+if NET_VENDOR_ALACRITECH
+
+config SLICOSS
+   tristate "Alacritech Slicoss support"
+   depends on PCI
+   select CRC32
+   ---help---
+ This driver supports Gigabit Ethernet adapters based on the
+ Session Layer Interface (SLIC) technology by Alacritech.
+
+ Supported are Mojave (1 port) and Oasis (1, 2 and 4 port) cards,
+ both copper and fiber.
+
+ To compile this driver as a module, choose M here: the module
+ will be called slicoss. This is recommended.
+
+endif # NET_VENDOR_ALACRITECH
diff --git a/drivers/net/ethernet/alacritech/Makefile 
b/drivers/net/ethernet/alacritech/Makefile
new file mode 100644
index 000..8790e9e
--- /dev/null
+++ b/drivers/net/ethernet/alacritech/Makefile
@@ -0,0 +1,4 @@
+#
+# Makefile for the Alacritech Slicoss driver
+#
+obj-$(CONFIG_SLICOSS) += slicoss.o
diff --git a/drivers/net/ethernet/alacritech/slic.h 
b/drivers/net/ethernet/alacritech/slic.h
new file mode 100644
index 000..08931b4
--- /dev/null
+++ b/drivers/net/ethernet/alacritech/slic.h
@@ -0,0 +1,575 @@
+
+#ifndef _SLIC_H
+#define _SLIC_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SLIC_VGBSTAT_XPERR 0x4000
+#define SLIC_VGBSTAT_XERRSHFT  25
+#define SLIC_VGBSTAT_XCSERR0x23
+#define SLIC_VGBSTAT_XUFLOW0x22
+#define SLIC_VGBSTAT_XHLEN 0x20
+#define SLIC_VGBSTAT_NETERR0x0100
+#define SLIC_VGBSTAT_NERRSHFT  16
+#define SLIC_VGBSTAT_NERRMSK   0x1ff
+#define SLIC_VGBSTAT_NCSERR0x103
+#define SLIC_VGBSTAT_NUFLOW0x102
+#define SLIC_VGBSTAT_NHLEN 0x100
+#define SLIC_VGBSTAT_LNKERR0x0080
+#define SLIC_VGBSTAT_LERRMSK   0xff
+#define SLIC_VGBSTAT_LDEARLY   0x86
+#define SLIC_VGBSTAT_LBOFLO0x85
+#define SLIC_VGBSTAT_LCODERR   0x84
+#define SLIC_VGBSTAT_LDBLNBL   0x83
+#define SLIC_VGBSTAT_LCRCERR   0x82
+#define SLIC_VGBSTAT_LOFLO 0x81
+#define SLIC_VGBSTAT_LUFLO 0x80
+

[PATCH v4 net-next 2/2] MAINTAINERS: add entry for slicoss ethernet driver

2016-12-05 Thread Lino Sanfilippo

Add myself as maintainer for the slicoss ethernet driver.

Signed-off-by: Lino Sanfilippo 
---
 MAINTAINERS | 5 +
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6781a3f..bb9af28 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -562,6 +562,11 @@ T: git git://linuxtv.org/anttip/media_tree.git
 S: Maintained
 F: drivers/media/usb/airspy/
 
+ALACRITECH GIGABIT ETHERNET DRIVER
+M: Lino Sanfilippo 
+S: Maintained
+F: drivers/net/ethernet/alacritech/*
+
 ALCATEL SPEEDTOUCH USB DRIVER
 M: Duncan Sands 
 L: linux-...@vger.kernel.org
-- 
1.9.1

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

Gigabit ethernet driver for Alacritechs SLIC devices (v4)

2016-12-05 Thread Lino Sanfilippo

Hi,

this is the forth version of the slicoss gigabit ethernet driver (which is a
rework of the driver from Alacritech which can currently be found under
drivers/staging/slicoss). The driver is supposed to support Mojave, Oasis and
Kalahari cards, for both copper and fiber.

If this code is accepted the staging version can be removed.

The driver has been tested on a SEN2104ET adapter (4 Port PCIe copper).

v4:
- fix wrong driver name in Kconfig file (reported by Rami Rosen)
- remove unused variable from driver struct (reported by Rami Rosen)
- return "err" instead of 0 in slic_load_rcvseq_firmware() (reported by Rami 
Rosen)
- Fix typos in constants, comments and error message (reported by Markus Böhme)
- fix various warnings concerning signedness (reported by Markus Böhme)
- improve line formatting (reported by Markus Böhme)
- add comment describing the need for SLIC_MAX_TX_COMPLETIONS (suggested by 
Florian Fainelli)
- do not zero out complete rx descriptor (suggested by Florian Fainelli)
- add missing write barrier (reported by Florian Fainelli)
- remove unneeded assignment of net_device to skb (reported by Florian Fainelli)
- use napi_complete_done() instead of napi_complete (suggested by Florian 
Fainelli)
- use napi_schedule_irqoff() instead of napi_schedule (suggested by Florian 
Fainelli)
- do not map error returned by slic_init() to -ENOMEM
- do proper dma syncs before and after rx descriptor status is set to 0
- if after dma sync for CPU rx descriptor is not used return it to HW by means 
of dma sync for device

v3:
- dont add defines to pci_ids.h but instead put it into the drivers header file
(requested by Greg Kroah-Hartman)

v2:
- remove unusual padding in statistic strings (suggested by Andrew Lunn)
- for mdio register and bit names use defines from mii.h instead of own ones
  (suggested by Andrew Lunn)
- remove unused defines
- ensure PCI flush at two more places
- use mmiowb before lock to prevent mmio writes leaking out of lock
- fix some typos in comments
- add copyright and GPL header

Regards,
Lino 

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

Re: [lustre-devel] [PATCH 3/6] staging: lustre: obdclass: Create a header for obdo related functions

2016-12-05 Thread Dan Carpenter

Sorry, I was unclear.  I have no problem with white space changes on
their own or when they are on the same line as something else you're
changing.

What I meant is that when you're just moving functions around then don't
mix unrelated white space changes into that patch.  I have automated
scripts for reviewing moving code around but slight changes mean that I
have to review it manually line by line to spot the difference.  I can
review a one liner cleanup in about 10 seconds but it's finding the line
which changed that's the problem in this case.

And I'm also fine with this patch since I already reviewed it, but in
the future, please avoid the temptation to do cleanups until after.

regards,
dan carpenter

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

Re: [lustre-devel] [PATCH 3/6] staging: lustre: obdclass: Create a header for obdo related functions

2016-12-05 Thread Dilger, Andreas

> On Dec 5, 2016, at 13:50, Dan Carpenter  wrote:
> 
> On Fri, Dec 02, 2016 at 02:40:47PM -0500, James Simmons wrote:
>> -__u32 local_flags = 0;
>> +u32 local_flags = 0;
> 
>> -if (local_flags != 0) {
>> +if (local_flags) {
> 
> Please avoid these unrelated white space changes.

Some projects (e.g. ext4 that I work with most) allow whitespace changes
as part of related changes to the code, since the code is being modified
anyway, and frown upon whitespace-only changes because they cause churn
in the code and otherwise introduce patch merge conflicts for relatively
minor benefits by themselves.

My preference is to allow whitespace cleanups in code being modified as
part of a patch that is making other fixes, since a few whitespace changes
don't typically make it any harder to review the patch.  If it gets so
far as moving blocks of code between files and this doesn't appear cleanly
in the patch then I'd ask for a separate patch.

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

Re: [PATCH 1/7] rtlwifi: btcoexist: Update routines for RTL8192EE

2016-12-05 Thread Dan Carpenter

On Mon, Dec 05, 2016 at 11:17:28AM -0600, Larry Finger wrote:
> On 12/05/2016 05:38 AM, Dan Carpenter wrote:
> >On Sat, Dec 03, 2016 at 11:32:01AM -0600, Larry Finger wrote:
> >>From: Ping-Ke Shih 
> >>
> >>The btcoexist routines for the RTL8192EE have been extensively rewritten.
> >>
> >
> >This patch does a million things and is totally unreviewable.  The
> >patch description doesn't say what patch does or why.  It's 5k lines
> >of diff.  What the heck???
> 
> I am caught in a bind. The BT coexistence routines are written by a
> Realtek contractor. As I cannot get the individual patches from
> Realtek, there is no chance of getting them from a 3rd party.

These patches are absolutely impenetrable.  A few years ago in SCSI we
gave a vendor a one time pass to just merge a huge patch and sync with
mainline.  We could view this in the same light, except that I think
when we moved this driver out of staging that was the one time pass.  By
now they should be proper kernel devs who can wipe their own bottoms...

We maybe should merge this and move the driver back to staging until
they can figure out how to maintain stuff?  That's a serious suggestion.
This patch is no way close to minimum quality requirements for upstream.

regards,
dan carpenter

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

Re: [PATCH 10/14] rtlwifi: Add BTC_TRACE_STRING to new btcoex

2016-12-05 Thread Dan Carpenter

On Thu, Dec 01, 2016 at 07:48:29PM -0600, Larry Finger wrote:
> --- 
> wireless-drivers-next.orig/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
> +++ 
> wireless-drivers-next/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
> @@ -27,6 +27,29 @@
>  
>  #include "../wifi.h"
>  
> +#ifdef CONFIG_RTLWIFI_DEBUG
> +
> +#define BTC_SPRINTF(ptr, ...)snprintf(ptr, ##__VA_ARGS__)
> +#define BTC_TRACE(fmt)   \
> +do { \
> + struct rtl_priv *rtlpriv = gl_bt_coexist.adapter;   \
> + if (!rtlpriv)   \
> + break;  \
> + RT_TRACE_STRING(rtlpriv, COMP_COEX, DBG_LOUD, fmt); \
> +} while (0)
> +

This sort of macro is exactly when the rtl drivers spent so long in
staging...  Subsystems should not invent their own tracing but in
particular these macros are so very very ugly.

It's just super frustrating to even look at this...

There are a lot of staging drivers I feel good about when they leave.
The HyperV drivers.  The IIO stuff.  A lot of the media stuff and
generally the media tree is getting better and better.  I like comedi
and unisys, those are in staging, but they are great and could move out
any time as far as I'm concerned.

But this patch just makes me super discouraged.  What are we doing???

regards,
dan carpenter

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

RE: [PATCH] pci-hyperv: use kmalloc to allocate hypercall params buffer

2016-12-05 Thread KY Srinivasan



> -Original Message-
> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On
> Behalf Of Cathy Avery
> Sent: Monday, December 5, 2016 4:54 AM
> To: Bjorn Helgaas ; Long Li 
> Cc: de...@linuxdriverproject.org
> Subject: Re: [PATCH] pci-hyperv: use kmalloc to allocate hypercall params
> buffer
> 
> Hi,
> 
> Is the double semicolon a typo?

Yes; it is a typo.

K. Y
> 
> Thanks,
> 
> Cathy
> 
> diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
> index 763ff87..ca553df 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -378,6 +378,8 @@ struct hv_pcibus_device {
>   struct msi_domain_info msi_info;
>   struct msi_controller msi_chip;
>   struct irq_domain *irq_domain;
> + struct retarget_msi_interrupt retarget_msi_interrupt_params;
> + spinlock_t retarget_msi_interrupt_lock;;
>   };
> 
> 
> 
> On 11/29/2016 06:25 PM, Bjorn Helgaas wrote:
> > On Tue, Nov 08, 2016 at 02:04:38PM -0800, Long Li wrote:
> >> From: Long Li 
> >>
> >> hv_do_hypercall assumes that we pass a segment from a physically
> >> continuous buffer. Buffer allocated on the stack may not work if
> >> CONFIG_VMAP_STACK=y is set.
> >>
> >> Change to use kmalloc to allocate this buffer.
> >>
> >> The v2 patch adds locking to access the pre-allocated buffer.
> >>
> >> Signed-off-by: Long Li 
> >> Reported-by: Haiyang Zhang 
> > Applied with KY's ack to pci/host-hv, thanks!
> >
> >> ---
> >>   drivers/pci/host/pci-hyperv.c | 29 +++--
> >>   1 file changed, 19 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
> >> index 763ff87..ca553df 100644
> >> --- a/drivers/pci/host/pci-hyperv.c
> >> +++ b/drivers/pci/host/pci-hyperv.c
> >> @@ -378,6 +378,8 @@ struct hv_pcibus_device {
> >>struct msi_domain_info msi_info;
> >>struct msi_controller msi_chip;
> >>struct irq_domain *irq_domain;
> >> +  struct retarget_msi_interrupt retarget_msi_interrupt_params;
> >> +  spinlock_t retarget_msi_interrupt_lock;;
> >>   };
> >>
> >>   /*
> >> @@ -774,34 +776,40 @@ 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);
> >> -  struct retarget_msi_interrupt params;
> >> +  struct retarget_msi_interrupt *params;
> >>struct hv_pcibus_device *hbus;
> >>struct cpumask *dest;
> >>struct pci_bus *pbus;
> >>struct pci_dev *pdev;
> >>int cpu;
> >> +  unsigned long flags;
> >>
> >>dest = irq_data_get_affinity_mask(data);
> >>pdev = msi_desc_to_pci_dev(msi_desc);
> >>pbus = pdev->bus;
> >>hbus = container_of(pbus->sysdata, struct hv_pcibus_device,
> sysdata);
> >>
> >> -  memset(, 0, sizeof(params));
> >> -  params.partition_id = HV_PARTITION_ID_SELF;
> >> -  params.source = 1; /* MSI(-X) */
> >> -  params.address = msi_desc->msg.address_lo;
> >> -  params.data = msi_desc->msg.data;
> >> -  params.device_id = (hbus->hdev->dev_instance.b[5] << 24) |
> >> +  spin_lock_irqsave(>retarget_msi_interrupt_lock, flags);
> >> +
> >> +  params = >retarget_msi_interrupt_params;
> >> +  memset(params, 0, sizeof(*params));
> >> +  params->partition_id = HV_PARTITION_ID_SELF;
> >> +  params->source = 1; /* MSI(-X) */
> >> +  params->address = msi_desc->msg.address_lo;
> >> +  params->data = msi_desc->msg.data;
> >> +  params->device_id = (hbus->hdev->dev_instance.b[5] << 24) |
> >>   (hbus->hdev->dev_instance.b[4] << 16) |
> >>   (hbus->hdev->dev_instance.b[7] << 8) |
> >>   (hbus->hdev->dev_instance.b[6] & 0xf8) |
> >>   PCI_FUNC(pdev->devfn);
> >> -  params.vector = cfg->vector;
> >> +  params->vector = cfg->vector;
> >>
> >>for_each_cpu_and(cpu, dest, cpu_online_mask)
> >> -  params.vp_mask |= (1ULL <<
> vmbus_cpu_number_to_vp_number(cpu));
> >> +  params->vp_mask |= (1ULL <<
> vmbus_cpu_number_to_vp_number(cpu));
> >> +
> >> +  hv_do_hypercall(HVCALL_RETARGET_INTERRUPT, params, NULL);
> >>
> >> -  hv_do_hypercall(HVCALL_RETARGET_INTERRUPT, , NULL);
> >> +  spin_unlock_irqrestore(>retarget_msi_interrupt_lock, flags);
> >>
> >>pci_msi_unmask_irq(data);
> >>   }
> >> @@ -2186,6 +2194,7 @@ static int hv_pci_probe(struct hv_device *hdev,
> >>INIT_LIST_HEAD(>resources_for_children);
> >>spin_lock_init(>config_lock);
> >>spin_lock_init(>device_list_lock);
> >> +  spin_lock_init(>retarget_msi_interrupt_lock);
> >>sema_init(>enum_sem, 1);
> >>init_completion(>remove_event);
> >>
> >> --
> >> 2.7.4
> >>
> >> --
> >> 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
>

Re: [PATCH 05/14] rtlwifi: Add TX report and disable key will wait until report acked.

2016-12-05 Thread Dan Carpenter

On Thu, Dec 01, 2016 at 07:48:24PM -0600, Larry Finger wrote:
> diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c 
> b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c
> index 2d48ccd..0f9d9f0 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c
> @@ -731,6 +731,14 @@ void rtl92ee_tx_fill_desc(struct ieee80211_hw *hw,
>   SET_TX_DESC_OFFSET(pdesc, USB_HWDESC_HEADER_LEN);
>   }
>  
> + /* tx report */
> + if (ptcb_desc->use_spe_rpt) {
> + u16 sn = rtl_get_tx_report_sn(hw);
> +
> + SET_TX_DESC_SPE_RPT(pdesc, 1);
> + SET_TX_DESC_SW_DEFINE(pdesc, sn);
> + }
> +

All the callers of rtl_get_tx_report_sn() use this same 5 line block.
Let's move it to a separate function.

regards,
dan carpenter

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

Re: [PATCH 05/22] staging: lustre: lmv: remove nlink check in lmv_revalidate_slaves

2016-12-05 Thread Dan Carpenter

On Fri, Dec 02, 2016 at 07:53:12PM -0500, James Simmons wrote:
> From: wang di 
> 
> Remove nlink < 2 check in lmv_revalidate_slaves, because
> after nlink reaches to LDISKFS_LINK_MAX (65000), the inode
> nlink will be set to 1.
> 

I don't understand how this changelog matches the patch...

The changelog says we're removing a check but really this is a NULL
dereference fix, right?  We're not really removing a check at all, just
changing it for something else.  We do remove a printk, though.

regards,
dan carpenter

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

Re: [PATCH 04/22] staging: lustre: osc: handle osc eviction correctly

2016-12-05 Thread Dan Carpenter

On Fri, Dec 02, 2016 at 07:53:11PM -0500, James Simmons wrote:
> @@ -3183,8 +3182,10 @@ static int discard_cb(const struct lu_env *env, struct 
> cl_io *io,
>   /* page is top page. */
>   info->oti_next_index = osc_index(ops) + 1;
>   if (cl_page_own(env, io, page) == 0) {
> - KLASSERT(ergo(page->cp_type == CPT_CACHEABLE,
> -   !PageDirty(cl_page_vmpage(page;
> + if (!ergo(page->cp_type == CPT_CACHEABLE,
> +   !PageDirty(cl_page_vmpage(page
> + CL_PAGE_DEBUG(D_ERROR, env, page,
> +   "discard dirty page?\n");


I don't understand the point of the ergo macro.  There are way too many
double negatives (some of them hidden for my small brain).  How is that
simpler than just writing it out:

if (page->cp_type == CPT_CACHEABLE &&
PageDirty(cl_page_vmpage(page))
 CL_PAGE_DEBUG(D_ERROR, env, page, "discard dirty page?\n");

regards,
dan carpenter

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

Re: [PATCH v3 20/28] staging: iio: tsl2583: don't assume an unsigned int is 32 bits

2016-12-05 Thread Dan Carpenter

On Thu, Nov 10, 2016 at 04:25:56AM -0500, Brian Masney wrote:
> in_illuminance_lux_table_store assumes that an unsigned int is 32 bits.

It's a totally safe assumption.  The only problem is that it's less
readable than sizeof().

regards,
dan carpenter

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

Re: [PATCH 5/6] staging: lustre: headers: Move functions out of lustre_idl.h

2016-12-05 Thread Dan Carpenter

On Fri, Dec 02, 2016 at 02:40:49PM -0500, James Simmons wrote:
> -/* If LDLM_ENQUEUE, 1 slot is already occupied, 1 is available.
> - * Otherwise, 2 are available.
> - */
> -#define ldlm_request_bufsize(count, type)\
> -({ \
> - int _avail = LDLM_LOCKREQ_HANDLES;\
> - _avail -= (type == LDLM_ENQUEUE ? LDLM_ENQUEUE_CANCEL_OFF : 0); \
> - sizeof(struct ldlm_request) +  \
> - (count > _avail ? count - _avail : 0) *  \
> - sizeof(struct lustre_handle);  \
> -})
> -

> +/**
> + * ldlm_request_bufsize
> + *
> + * @count:   number of ldlm handles
> + * @type:ldlm opcode
> + *
> + * If opcode=LDLM_ENQUEUE, 1 slot is already occupied,
> + * LDLM_LOCKREQ_HANDLE -1 slots are available.
> + * Otherwise, LDLM_LOCKREQ_HANDLE slots are available.
> + *
> + * Return:   size of the request buffer
> + */
> +int ldlm_request_bufsize(int count, int type)
> +{
> + int avail = LDLM_LOCKREQ_HANDLES;
> +
> + if (type == LDLM_ENQUEUE)
> + avail -= LDLM_ENQUEUE_CANCEL_OFF;
> +
> + if (count > avail)
> + avail = (count - avail) * sizeof(struct lustre_handle);
> + else
> + avail = 0;
> +
> + return sizeof(struct ldlm_request) + avail;
> +}
> +

This is a nice cleanup.

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

Re: [PATCH 12/19] staging: iio: isl29028: fix comparison between signed and unsigned integers

2016-12-05 Thread Dan Carpenter

On Sat, Dec 03, 2016 at 09:19:36PM -0500, Brian Masney wrote:
> Fixed warning found by make W=2 to reduce the amount of build noise:
> 
> warning: comparison between signed and unsigned integer expressions
> [-Wsign-compare]

Ugh...  Please don't do work arounds for nonsense warnings.  W=2 is so
stupid.  Better to just grep -v this warning instead of trying to please
a broken static analysis.  Warnings like this are why it's disabled by
default.

regards,
dan carpenter

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

Re: [PATCH v3 4/9] bus: fsl-mc: dpio: add frame descriptor and scatter/gather APIs

2016-12-05 Thread Dan Carpenter

On Fri, Dec 02, 2016 at 12:12:14PM +, Laurentiu Tudor wrote:
> > +static inline bool dpaa2_sg_is_final(const struct dpaa2_sg_entry *sg)
> > +{
> > +   return !!(le16_to_cpu(sg->format_offset) >> SG_FINAL_FLAG_SHIFT);
> 
> In other places in this file we don't use the '!!' to convert to bool. Maybe 
> we should drop it here too.

I like the explicit "!!".  I think it makes the code more obvious since
all the information is on one line.

regards,
dan carpenter

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

Re: [PATCH] staging: lustre: Fix a spatch warning due to an assignment from kernel to user space

2016-12-05 Thread Dan Carpenter

On Fri, Dec 02, 2016 at 06:33:32PM +0100, Quentin Lambert wrote:
> lnet_ipif_enumerate was assigning a pointer from kernel space to user
> space. This patch uses copy_to_user to properly do that assignment.

Put the exact warning message here.

> 
> Signed-off-by: Quentin Lambert 
> ---
>  shouldn't we be using ifc_req instead of ifc_buf?
> 
>  drivers/staging/lustre/lnet/lnet/lib-socket.c |8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> --- a/drivers/staging/lustre/lnet/lnet/lib-socket.c
> +++ b/drivers/staging/lustre/lnet/lnet/lib-socket.c
> @@ -181,7 +181,13 @@ lnet_ipif_enumerate(char ***namesp)
>   goto out0;
>   }
>  
> - ifc.ifc_buf = (char *)ifr;
> + rc = copy_to_user(ifc.ifc_buf, (char *)ifr,
> +   nalloc * sizeof(*ifr));
> + if (rc) {
> + rc = -ENOMEM;
> + goto out1;
> + }


No idea what's going on here.  The original code is correct.

regards,
dan carpenter


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

Re: [PATCH] staging: dgnc: Fix lines longer than 80 characters

2016-12-05 Thread Dan Carpenter

On Fri, Dec 02, 2016 at 08:13:49PM +0100, Fernando Apesteguia wrote:
> For the first lines of the patch, I opted to create a small function
> instead of breaking the the line in a weird way.

These first ones are the nice.

> @@ -2511,13 +2516,15 @@ static int dgnc_tty_ioctl(struct tty_struct *tty, 
> unsigned int cmd,
>   if (ch->ch_tun.un_flags & (UN_LOW | UN_EMPTY)) {
>   ch->ch_tun.un_flags &=
>   ~(UN_LOW | UN_EMPTY);
> - 
> wake_up_interruptible(>ch_tun.un_flags_wait);
> + wake_up_interruptible(>ch_tun
> + .un_flags_wait);


Ugh...  No.  Don't do this.  Just let it go over 80 characters.  Ignore
the warning.

regards,
dan carpenter

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

Re: [PATCH 02/14] rtlwifi: Fix programing CAM content sequence.

2016-12-05 Thread Dan Carpenter

On Thu, Dec 01, 2016 at 07:48:21PM -0600, Larry Finger wrote:
> From: Ping-Ke Shih 
> 
> There is a potential race condition when the control byte of a CAM
> entry is written first. Write in reverse order to correct the condition.
> 
> Signed-off-by: Ping-Ke Shih 
> Signed-off-by: shaofu 
> Signed-off-by: Larry Finger 
> ---
>  drivers/net/wireless/realtek/rtlwifi/cam.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtlwifi/cam.c 
> b/drivers/net/wireless/realtek/rtlwifi/cam.c
> index 8fe8b4c..5d58ec0 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/cam.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/cam.c
> @@ -45,12 +45,13 @@ static void rtl_cam_program_entry(struct ieee80211_hw 
> *hw, u32 entry_no,
>  
>   u32 target_command;
>   u32 target_content = 0;
> - u8 entry_i;
> + s8 entry_i;

Just make this an int.  s8 is for very specific things like hardware
registers.

regards,
dan carpenter

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

Re: [PATCH 3/6] staging: lustre: obdclass: Create a header for obdo related functions

2016-12-05 Thread Dan Carpenter

On Fri, Dec 02, 2016 at 02:40:47PM -0500, James Simmons wrote:
> - __u32 local_flags = 0;
> + u32 local_flags = 0;

> - if (local_flags != 0) {
> + if (local_flags) {

Please avoid these unrelated white space changes.

regards,
dan carpenter

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

Re: [PATCH 1/1] staging: android: ashmem: convert range macros to inlines and clean-up

2016-12-05 Thread Guillaume Tucker

On 12/05/16 18:08, Greg Kroah-Hartman wrote:
> On Mon, Dec 05, 2016 at 05:34:15PM +, Guillaume Tucker wrote:
>> Convert ashmem_range related macros to inline functions to fix
>> checkpatch errors.  Clean up the code in related existing inline
>> functions.
> 
> How about breaking this up into two different patches, one for the
> inlines, and one to fix up the existing inline functions for coding
> style issues?
> 
> thanks,
> 
> greg k-h

Sure, thanks.  I've sent a v2.

(and sorry the series still doesn't seem to be treated as a thread in
spite of the In-Reply-To: and References: headers being there...)

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

[PATCH v2 2/2] staging: android: ashmem: clean up range inline functions

2016-12-05 Thread Guillaume Tucker

Clean up the code in inline functions that deal with page and
range addresses.  Use bool instead of int for boolean return
types and remove superfluous brackets.

Signed-off-by: Guillaume Tucker 
---
 drivers/staging/android/ashmem.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index facc8a24..7cbad0d 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -110,33 +110,33 @@ static inline bool range_on_lru(struct ashmem_range 
*range)
return range->purged == ASHMEM_NOT_PURGED;
 }
 
-static inline int page_range_subsumes_range(struct ashmem_range *range,
-   size_t start, size_t end)
+static inline bool page_range_subsumes_range(struct ashmem_range *range,
+size_t start, size_t end)
 {
-   return (((range)->pgstart >= (start)) && ((range)->pgend <= (end)));
+   return (range->pgstart >= start) && (range->pgend <= end);
 }
 
-static inline int page_range_subsumed_by_range(struct ashmem_range *range,
-  size_t start, size_t end)
+static inline bool page_range_subsumed_by_range(struct ashmem_range *range,
+   size_t start, size_t end)
 {
-   return (((range)->pgstart <= (start)) && ((range)->pgend >= (end)));
+   return (range->pgstart <= start) && (range->pgend >= end);
 }
 
-static inline int page_in_range(struct ashmem_range *range, size_t page)
+static inline bool page_in_range(struct ashmem_range *range, size_t page)
 {
-   return (((range)->pgstart <= (page)) && ((range)->pgend >= (page)));
+   return (range->pgstart <= page) && (range->pgend >= page);
 }
 
-static inline int page_range_in_range(struct ashmem_range *range,
- size_t start, size_t end)
+static inline bool page_range_in_range(struct ashmem_range *range,
+  size_t start, size_t end)
 {
-   return (page_in_range(range, start) || page_in_range(range, end) ||
-   page_range_subsumes_range(range, start, end));
+   return page_in_range(range, start) || page_in_range(range, end) ||
+   page_range_subsumes_range(range, start, end);
 }
 
-static inline int range_before_page(struct ashmem_range *range, size_t page)
+static inline bool range_before_page(struct ashmem_range *range, size_t page)
 {
-   return ((range)->pgend < (page));
+   return range->pgend < page;
 }
 
 #define PROT_MASK  (PROT_EXEC | PROT_READ | PROT_WRITE)
-- 
2.8.1.116.g7b0d47b

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

[PATCH v2 1/2] staging: android: ashmem: convert range macros to inlines

2016-12-05 Thread Guillaume Tucker

Convert range_size and range_on_lru macros to inline functions to
fix checkpatch check:

  CHECK: Macro argument reuse 'range' - possible side-effects?

Signed-off-by: Guillaume Tucker 
---
 drivers/staging/android/ashmem.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index ca9a53c..facc8a24 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -100,11 +100,15 @@ static DEFINE_MUTEX(ashmem_mutex);
 static struct kmem_cache *ashmem_area_cachep __read_mostly;
 static struct kmem_cache *ashmem_range_cachep __read_mostly;
 
-#define range_size(range) \
-   ((range)->pgend - (range)->pgstart + 1)
+static inline unsigned long range_size(struct ashmem_range *range)
+{
+   return range->pgend - range->pgstart + 1;
+}
 
-#define range_on_lru(range) \
-   ((range)->purged == ASHMEM_NOT_PURGED)
+static inline bool range_on_lru(struct ashmem_range *range)
+{
+   return range->purged == ASHMEM_NOT_PURGED;
+}
 
 static inline int page_range_subsumes_range(struct ashmem_range *range,
size_t start, size_t end)
-- 
2.8.1.116.g7b0d47b

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

[PATCH v2 0/2] staging: android: ashmem: convert range macros to inlines and clean-up

2016-12-05 Thread Guillaume Tucker

This is to fix some checkpatch.pl checks by converting macros to static inline
functions and do a bit of clean-up in existing inline functions.  I've run some
Android unit tests on a HiKey board and made a small kernel-side test function
to sanity check it.

I realise this code is a bit stale so it's probably not the most pressing thing
to fix in the kernel but it's the first patch I'm sending so I thought I'd pick
something easy to start with and put me through my paces.  I hope it'll be
useful anyway.

Guillaume Tucker (2):
  staging: android: ashmem: convert range macros to inlines
  staging: android: ashmem: clean up range inline functions

 drivers/staging/android/ashmem.c | 40 ++--
 1 file changed, 22 insertions(+), 18 deletions(-)

-- 
2.8.1.116.g7b0d47b

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

Re: [PATCH 1/1] staging: android: ashmem: convert range macros to inlines and clean-up

2016-12-05 Thread Greg Kroah-Hartman

On Mon, Dec 05, 2016 at 05:34:15PM +, Guillaume Tucker wrote:
> Convert ashmem_range related macros to inline functions to fix
> checkpatch errors.  Clean up the code in related existing inline
> functions.

How about breaking this up into two different patches, one for the
inlines, and one to fix up the existing inline functions for coding
style issues?

thanks,

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

[PATCH 1/1] staging: android: ashmem: convert range macros to inlines and clean-up

2016-12-05 Thread Guillaume Tucker

Convert ashmem_range related macros to inline functions to fix
checkpatch errors.  Clean up the code in related existing inline
functions.

Signed-off-by: Guillaume Tucker 
---
 drivers/staging/android/ashmem.c | 40 ++--
 1 file changed, 22 insertions(+), 18 deletions(-)

diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index ca9a53c..7cbad0d 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -100,39 +100,43 @@ static DEFINE_MUTEX(ashmem_mutex);
 static struct kmem_cache *ashmem_area_cachep __read_mostly;
 static struct kmem_cache *ashmem_range_cachep __read_mostly;
 
-#define range_size(range) \
-   ((range)->pgend - (range)->pgstart + 1)
+static inline unsigned long range_size(struct ashmem_range *range)
+{
+   return range->pgend - range->pgstart + 1;
+}
 
-#define range_on_lru(range) \
-   ((range)->purged == ASHMEM_NOT_PURGED)
+static inline bool range_on_lru(struct ashmem_range *range)
+{
+   return range->purged == ASHMEM_NOT_PURGED;
+}
 
-static inline int page_range_subsumes_range(struct ashmem_range *range,
-   size_t start, size_t end)
+static inline bool page_range_subsumes_range(struct ashmem_range *range,
+size_t start, size_t end)
 {
-   return (((range)->pgstart >= (start)) && ((range)->pgend <= (end)));
+   return (range->pgstart >= start) && (range->pgend <= end);
 }
 
-static inline int page_range_subsumed_by_range(struct ashmem_range *range,
-  size_t start, size_t end)
+static inline bool page_range_subsumed_by_range(struct ashmem_range *range,
+   size_t start, size_t end)
 {
-   return (((range)->pgstart <= (start)) && ((range)->pgend >= (end)));
+   return (range->pgstart <= start) && (range->pgend >= end);
 }
 
-static inline int page_in_range(struct ashmem_range *range, size_t page)
+static inline bool page_in_range(struct ashmem_range *range, size_t page)
 {
-   return (((range)->pgstart <= (page)) && ((range)->pgend >= (page)));
+   return (range->pgstart <= page) && (range->pgend >= page);
 }
 
-static inline int page_range_in_range(struct ashmem_range *range,
- size_t start, size_t end)
+static inline bool page_range_in_range(struct ashmem_range *range,
+  size_t start, size_t end)
 {
-   return (page_in_range(range, start) || page_in_range(range, end) ||
-   page_range_subsumes_range(range, start, end));
+   return page_in_range(range, start) || page_in_range(range, end) ||
+   page_range_subsumes_range(range, start, end);
 }
 
-static inline int range_before_page(struct ashmem_range *range, size_t page)
+static inline bool range_before_page(struct ashmem_range *range, size_t page)
 {
-   return ((range)->pgend < (page));
+   return range->pgend < page;
 }
 
 #define PROT_MASK  (PROT_EXEC | PROT_READ | PROT_WRITE)
-- 
2.8.1.116.g7b0d47b

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

[PATCH 0/1] staging: android: ashmem: convert range macros to inlines and clean-up

2016-12-05 Thread Guillaume Tucker

This is to fix some checkpatch.pl errors by converting macros to static inline
functions and do a bit of clean-up in existing inline functions.  I've run some
Android unit tests on a HiKey board and made a small kernel-side test function
to sanity check it.

I realise this code is a bit stale so it's probably not the most pressing thing
to fix in the kernel but it's the first patch I'm sending so I thought I'd pick
something easy to start with and put me through my paces.  I hope it'll be
useful anyway.

Guillaume Tucker (1):
  staging: android: ashmem: convert range macros to inlines and clean-up

 drivers/staging/android/ashmem.c | 40 ++--
 1 file changed, 22 insertions(+), 18 deletions(-)

-- 
2.8.1.116.g7b0d47b

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

Re: [PATCH] Staging: comedi: kcomedilib: Add module_init/exit function

2016-12-05 Thread Ian Abbott


On 05/12/16 16:57, Cheah Kok Cheong wrote:

Add init/exit function to follow LKM semantics.
Apparently this module can still load/unload without
the init/exit function.

Tested loading/unloading with and without this patch.

Signed-off-by: Cheah Kok Cheong 
---
 drivers/staging/comedi/kcomedilib/kcomedilib_main.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/staging/comedi/kcomedilib/kcomedilib_main.c 
b/drivers/staging/comedi/kcomedilib/kcomedilib_main.c
index d0a8a28..55d43c0 100644
--- a/drivers/staging/comedi/kcomedilib/kcomedilib_main.c
+++ b/drivers/staging/comedi/kcomedilib/kcomedilib_main.c
@@ -250,3 +250,15 @@ int comedi_get_n_channels(struct comedi_device *dev, 
unsigned int subdevice)
return n;
 }
 EXPORT_SYMBOL_GPL(comedi_get_n_channels);
+
+static int __init kcomedilib_module_init(void)
+{
+   return 0;
+}
+
+static void __exit kcomedilib_module_exit(void)
+{
+}
+
+module_init(kcomedilib_module_init);
+module_exit(kcomedilib_module_exit);



Looks good, thanks!

Reviewed-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/7] rtlwifi: btcoexist: Update routines for RTL8192EE

2016-12-05 Thread Larry Finger


On 12/05/2016 05:38 AM, Dan Carpenter wrote:

On Sat, Dec 03, 2016 at 11:32:01AM -0600, Larry Finger wrote:

From: Ping-Ke Shih 

The btcoexist routines for the RTL8192EE have been extensively rewritten.



This patch does a million things and is totally unreviewable.  The
patch description doesn't say what patch does or why.  It's 5k lines
of diff.  What the heck???


I am caught in a bind. The BT coexistence routines are written by a Realtek 
contractor. As I cannot get the individual patches from Realtek, there is no 
chance of getting them from a 3rd party.


Larry


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

[PATCH] Staging: comedi: kcomedilib: Add module_init/exit function

2016-12-05 Thread Cheah Kok Cheong

Add init/exit function to follow LKM semantics.
Apparently this module can still load/unload without
the init/exit function.

Tested loading/unloading with and without this patch.

Signed-off-by: Cheah Kok Cheong 
---
 drivers/staging/comedi/kcomedilib/kcomedilib_main.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/staging/comedi/kcomedilib/kcomedilib_main.c 
b/drivers/staging/comedi/kcomedilib/kcomedilib_main.c
index d0a8a28..55d43c0 100644
--- a/drivers/staging/comedi/kcomedilib/kcomedilib_main.c
+++ b/drivers/staging/comedi/kcomedilib/kcomedilib_main.c
@@ -250,3 +250,15 @@ int comedi_get_n_channels(struct comedi_device *dev, 
unsigned int subdevice)
return n;
 }
 EXPORT_SYMBOL_GPL(comedi_get_n_channels);
+
+static int __init kcomedilib_module_init(void)
+{
+   return 0;
+}
+
+static void __exit kcomedilib_module_exit(void)
+{
+}
+
+module_init(kcomedilib_module_init);
+module_exit(kcomedilib_module_exit);
-- 
2.7.4

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

Re: [PATCH] pci-hyperv: use kmalloc to allocate hypercall params buffer

2016-12-05 Thread Stephen Hemminger

On Tue,  8 Nov 2016 14:04:38 -0800
Long Li  wrote:

> + spin_lock_irqsave(>retarget_msi_interrupt_lock, flags);
> +
> + params = >retarget_msi_interrupt_params;
> + memset(params, 0, sizeof(*params));
> + params->partition_id = HV_PARTITION_ID_SELF;
> + params->source = 1; /* MSI(-X) */
> + params->address = msi_desc->msg.address_lo;
> + params->data = msi_desc->msg.data;
> + params->device_id = (hbus->hdev->dev_instance.b[5] << 24) |
>  (hbus->hdev->dev_instance.b[4] << 16) |
>  (hbus->hdev->dev_instance.b[7] << 8) |
>  (hbus->hdev->dev_instance.b[6] & 0xf8) |
>  PCI_FUNC(pdev->devfn);
> - params.vector = cfg->vector;
> + params->vector = cfg->vector;
>  
>   for_each_cpu_and(cpu, dest, cpu_online_mask)
> - params.vp_mask |= (1ULL << vmbus_cpu_number_to_vp_number(cpu));
> + params->vp_mask |= (1ULL << vmbus_cpu_number_to_vp_number(cpu));
> +
> + hv_do_hypercall(HVCALL_RETARGET_INTERRUPT, params, NULL);
>  
> - hv_do_hypercall(HVCALL_RETARGET_INTERRUPT, , NULL);
> + spin_unlock_irqrestore(>retarget_msi_interrupt_lock, flags);

It looks like the additional locking here is being overly paranoid.
The caller is already holding the irq descriptor lock. Look at fixup_irqs.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH 04/15] Drivers: hv: vmbus: Prevent sending data on a rescinded channel

2016-12-05 Thread KY Srinivasan



> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Monday, December 5, 2016 2:01 AM
> To: KY Srinivasan 
> Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> vkuzn...@redhat.com; jasow...@redhat.com;
> leann.ogasaw...@canonical.com
> Subject: Re: [PATCH 04/15] Drivers: hv: vmbus: Prevent sending data on a
> rescinded channel
> 
> On Thu, Dec 01, 2016 at 09:28:41AM -0800, k...@exchange.microsoft.com
> wrote:
> > From: K. Y. Srinivasan 
> >
> > After the channel is rescinded, the host does not read from the rescinded
> channel.
> > Fail writes to a channel that has already been rescinded
> 
> What are the user visible effects of this bug?  Presumably none right
> since it doesn't need to be back ported.
> 
> But it's absolutely impossible to tell from the commit message.

Thanks Dan. I will update the commit log and resend.

K. Y

> 
> regards,
> dan carpenter

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

[PATCH 2/2] Staging: dgnc: dgnc_neo.c: Use usleep_range over udelay to improve coalescing processor wakeups

2016-12-05 Thread Shiva Kerdel

In most cases, usleep_range is better than udelay, as the precise wakeup
from udelay is unnecessary.

usleep_range gives a much better chance of coalescing processor wakeups.

Signed-off-by: Shiva Kerdel 
---
 drivers/staging/dgnc/dgnc_neo.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index 3eefefe..20bc271 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -1352,7 +1352,7 @@ static void neo_flush_uart_write(struct channel_t *ch)
 */
tmp = readb(>ch_neo_uart->isr_fcr);
if (tmp & 4)
-   udelay(10);
+   usleep_range(10, 20);
else
break;
}
@@ -1384,7 +1384,7 @@ static void neo_flush_uart_read(struct channel_t *ch)
 */
tmp = readb(>ch_neo_uart->isr_fcr);
if (tmp & 2)
-   udelay(10);
+   usleep_range(10, 20);
else
break;
}
@@ -1616,7 +1616,7 @@ static void neo_assert_modem_signals(struct channel_t *ch)
neo_pci_posting_flush(ch->ch_bd);
 
/* Give time for the UART to actually raise/drop the signals */
-   udelay(10);
+   usleep_range(10, 20);
 }
 
 static void neo_send_start_character(struct channel_t *ch)
@@ -1628,7 +1628,7 @@ static void neo_send_start_character(struct channel_t *ch)
ch->ch_xon_sends++;
writeb(ch->ch_startc, >ch_neo_uart->txrx);
neo_pci_posting_flush(ch->ch_bd);
-   udelay(10);
+   usleep_range(10, 20);
}
 }
 
@@ -1641,7 +1641,7 @@ static void neo_send_stop_character(struct channel_t *ch)
ch->ch_xoff_sends++;
writeb(ch->ch_stopc, >ch_neo_uart->txrx);
neo_pci_posting_flush(ch->ch_bd);
-   udelay(10);
+   usleep_range(10, 20);
}
 }
 
-- 
2.10.2

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

[PATCH 1/2] Staging: dgnc: dgnc_cls.c: Use usleep_range over udelay to improve coalescing processor wakeups

2016-12-05 Thread Shiva Kerdel

In most cases, usleep_range is better than udelay, as the precise wakeup
from udelay is unnecessary.

usleep_range gives a much better chance of coalescing processor wakeups.

Signed-off-by: Shiva Kerdel 
---
 drivers/staging/dgnc/dgnc_cls.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_cls.c b/drivers/staging/dgnc/dgnc_cls.c
index c20ffdd..6607243a 100644
--- a/drivers/staging/dgnc/dgnc_cls.c
+++ b/drivers/staging/dgnc/dgnc_cls.c
@@ -409,7 +409,7 @@ static void cls_assert_modem_signals(struct channel_t *ch)
writeb(out, >ch_cls_uart->mcr);
 
/* Give time for the UART to actually drop the signals */
-   udelay(10);
+   usleep_range(10, 20);
 }
 
 static void cls_copy_data_from_queue_to_uart(struct channel_t *ch)
@@ -631,7 +631,7 @@ static void cls_flush_uart_read(struct channel_t *ch)
 * Presumably, this is a bug in this UART.
 */
 
-   udelay(10);
+   usleep_range(10, 20);
 }
 
 /*
@@ -1096,7 +1096,7 @@ static void cls_uart_init(struct channel_t *ch)
 
writeb(UART_FCR_ENABLE_FIFO | UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT,
   >ch_cls_uart->isr_fcr);
-   udelay(10);
+   usleep_range(10, 20);
 
ch->ch_flags |= (CH_FIFO_ENABLED | CH_TX_FIFO_EMPTY | CH_TX_FIFO_LWM);
 
-- 
2.10.2

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

[PATCH v3] Staging: wlan-ng: hfa384x_usb.c Fixed too long code line warnings.

2016-12-05 Thread Yan Laijun

Fixed checkpatch warning "line over 80 characters" in
wlan-ng/hfa384x_usb.c file.

Signed-off-by: Yan Laijun 
---
Changes in v2:
  - Remove initialization of usbin on its decarlation.
---
Changes in v3:
  - Move usbin's assignment to where it's used for the first time.
---
 drivers/staging/wlan-ng/hfa384x_usb.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c 
b/drivers/staging/wlan-ng/hfa384x_usb.c
index 5f11f6e..4fe037a 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -3037,7 +3037,7 @@ static void hfa384x_usbin_callback(struct urb *urb)
 {
struct wlandevice *wlandev = urb->context;
struct hfa384x *hw;
-   union hfa384x_usbin *usbin = (union hfa384x_usbin 
*)urb->transfer_buffer;
+   union hfa384x_usbin *usbin;
struct sk_buff *skb = NULL;
int result;
int urb_status;
@@ -3139,6 +3139,7 @@ static void hfa384x_usbin_callback(struct urb *urb)
/* Note: the check of the sw_support field, the type field doesn't
 *   have bit 12 set like the docs suggest.
 */
+   usbin = (union hfa384x_usbin *)urb->transfer_buffer;
type = le16_to_cpu(usbin->type);
if (HFA384x_USB_ISRXFRM(type)) {
if (action == HANDLE) {
-- 
1.9.1

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

Re: [PATCH] pci-hyperv: use kmalloc to allocate hypercall params buffer

2016-12-05 Thread Cathy Avery


Hi,

Is the double semicolon a typo?

Thanks,

Cathy

diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index 763ff87..ca553df 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -378,6 +378,8 @@ struct hv_pcibus_device {
struct msi_domain_info msi_info;
struct msi_controller msi_chip;
struct irq_domain *irq_domain;
+   struct retarget_msi_interrupt retarget_msi_interrupt_params;
+   spinlock_t retarget_msi_interrupt_lock;;
 };



On 11/29/2016 06:25 PM, Bjorn Helgaas wrote:

On Tue, Nov 08, 2016 at 02:04:38PM -0800, Long Li wrote:

From: Long Li 

hv_do_hypercall assumes that we pass a segment from a physically
continuous buffer. Buffer allocated on the stack may not work if
CONFIG_VMAP_STACK=y is set.

Change to use kmalloc to allocate this buffer.

The v2 patch adds locking to access the pre-allocated buffer.

Signed-off-by: Long Li 
Reported-by: Haiyang Zhang 

Applied with KY's ack to pci/host-hv, thanks!


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

diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index 763ff87..ca553df 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -378,6 +378,8 @@ struct hv_pcibus_device {
struct msi_domain_info msi_info;
struct msi_controller msi_chip;
struct irq_domain *irq_domain;
+   struct retarget_msi_interrupt retarget_msi_interrupt_params;
+   spinlock_t retarget_msi_interrupt_lock;;
  };
  
  /*

@@ -774,34 +776,40 @@ 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);
-   struct retarget_msi_interrupt params;
+   struct retarget_msi_interrupt *params;
struct hv_pcibus_device *hbus;
struct cpumask *dest;
struct pci_bus *pbus;
struct pci_dev *pdev;
int cpu;
+   unsigned long flags;
  
  	dest = irq_data_get_affinity_mask(data);

pdev = msi_desc_to_pci_dev(msi_desc);
pbus = pdev->bus;
hbus = container_of(pbus->sysdata, struct hv_pcibus_device, sysdata);
  
-	memset(, 0, sizeof(params));

-   params.partition_id = HV_PARTITION_ID_SELF;
-   params.source = 1; /* MSI(-X) */
-   params.address = msi_desc->msg.address_lo;
-   params.data = msi_desc->msg.data;
-   params.device_id = (hbus->hdev->dev_instance.b[5] << 24) |
+   spin_lock_irqsave(>retarget_msi_interrupt_lock, flags);
+
+   params = >retarget_msi_interrupt_params;
+   memset(params, 0, sizeof(*params));
+   params->partition_id = HV_PARTITION_ID_SELF;
+   params->source = 1; /* MSI(-X) */
+   params->address = msi_desc->msg.address_lo;
+   params->data = msi_desc->msg.data;
+   params->device_id = (hbus->hdev->dev_instance.b[5] << 24) |
   (hbus->hdev->dev_instance.b[4] << 16) |
   (hbus->hdev->dev_instance.b[7] << 8) |
   (hbus->hdev->dev_instance.b[6] & 0xf8) |
   PCI_FUNC(pdev->devfn);
-   params.vector = cfg->vector;
+   params->vector = cfg->vector;
  
  	for_each_cpu_and(cpu, dest, cpu_online_mask)

-   params.vp_mask |= (1ULL << vmbus_cpu_number_to_vp_number(cpu));
+   params->vp_mask |= (1ULL << vmbus_cpu_number_to_vp_number(cpu));
+
+   hv_do_hypercall(HVCALL_RETARGET_INTERRUPT, params, NULL);
  
-	hv_do_hypercall(HVCALL_RETARGET_INTERRUPT, , NULL);

+   spin_unlock_irqrestore(>retarget_msi_interrupt_lock, flags);
  
  	pci_msi_unmask_irq(data);

  }
@@ -2186,6 +2194,7 @@ static int hv_pci_probe(struct hv_device *hdev,
INIT_LIST_HEAD(>resources_for_children);
spin_lock_init(>config_lock);
spin_lock_init(>device_list_lock);
+   spin_lock_init(>retarget_msi_interrupt_lock);
sema_init(>enum_sem, 1);
init_completion(>remove_event);
  
--

2.7.4

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



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

Re: [PATCH 1/7] rtlwifi: btcoexist: Update routines for RTL8192EE

2016-12-05 Thread Dan Carpenter

On Sat, Dec 03, 2016 at 11:32:01AM -0600, Larry Finger wrote:
> From: Ping-Ke Shih 
> 
> The btcoexist routines for the RTL8192EE have been extensively rewritten.
> 

This patch does a million things and is totally unreviewable.  The
patch description doesn't say what patch does or why.  It's 5k lines
of diff.  What the heck???

regards,
dan carpenter

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

[patch] staging: lustre: cl_page: fix a typo in comments

2016-12-05 Thread Dan Carpenter

We want to "sever" all the ways to get a new pointer to "pg".

Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/lustre/lustre/obdclass/cl_page.c 
b/drivers/staging/lustre/lustre/obdclass/cl_page.c
index bdc0aa5846ef..cd9a40ca4448 100644
--- a/drivers/staging/lustre/lustre/obdclass/cl_page.c
+++ b/drivers/staging/lustre/lustre/obdclass/cl_page.c
@@ -667,7 +667,7 @@ static void cl_page_delete0(const struct lu_env *env, 
struct cl_page *pg)
PASSERT(env, pg, pg->cp_state != CPS_FREEING);
 
/*
-* Severe all ways to obtain new pointers to @pg.
+* Sever all ways to obtain new pointers to @pg.
 */
cl_page_owner_clear(pg);
 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 04/15] Drivers: hv: vmbus: Prevent sending data on a rescinded channel

2016-12-05 Thread Dan Carpenter

On Thu, Dec 01, 2016 at 09:28:41AM -0800, k...@exchange.microsoft.com wrote:
> From: K. Y. Srinivasan 
> 
> After the channel is rescinded, the host does not read from the rescinded 
> channel.
> Fail writes to a channel that has already been rescinded

What are the user visible effects of this bug?  Presumably none right
since it doesn't need to be back ported.

But it's absolutely impossible to tell from the commit message.

regards,
dan carpenter

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

51 matches

Mail list logo