Greg,
Please drop this series of patches. Once the new rtl8192e and the follow-on
patches that I submitted are merged in staging, I will be sending a complete new
set of patches that remove the typedefs.
Thanks,
Larry
=
Th
Good-day to you ,
I would like to discuss the possibility of your company /your person,partaking
in an Government contract supply to Iraq.We are determined to purchase your
products in large quantities, for use in all over our 18 Governorates
(provinces) as the task of re-building Iraq covers
You are receiving this email because we wish you to use our 3D/2D animation
services.
We are a China based animation studio. We are specialized in providing 3D
designing/modelling/animation services across the globe. We utilize the finest
equipment available in the industry, offer efficient dat
On Mon, 2011-08-01 at 17:33 +0800, Leonid V. Fedorenchik wrote:
> Fix too long lines in cx25821-audio.h and cx25821-core.c
[]
> diff --git a/drivers/staging/cx25821/cx25821-core.c
> b/drivers/staging/cx25821/cx25821-core.c
[]
> @@ -972,8 +972,8 @@ static int cx25821_dev_setup(struct cx25821_dev *d
On 01/08/11 15:31, Manohar Vanga wrote:
> Hi Martyn,
>
>> I assume this is in a system where there are more than one type of bridge
>> (i.e. a ca91c042 and tsi148).
>
> Yes. This is referring to multiple bridges on a single PCI bus (in the case of
> the existing bridges). In practice we have only
Hi Martyn,
> Please can you update the vme_api.txt document as well to fully reflect the
> proposed changes.
Yikes forgot to do this. I'll modify and resend :)
--
/manohar
___
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriver
Hi Martyn,
> I assume this is in a system where there are more than one type of bridge
> (i.e. a ca91c042 and tsi148).
Yes. This is referring to multiple bridges on a single PCI bus (in the case of
the existing bridges). In practice we have only a single bridge of a single
type. We can however ha
On 01/08/11 11:20, Manohar Vanga wrote:
> A little background: I work at CERN in the device drivers section and
> we have a lot of VME crates we use in the accelerator controls. We have
> been using an in-house driver for some time now and want to slowly port
> our existing device drivers over to t
On 01/08/11 15:00, Manohar Vanga wrote:
> Hi Martyn,
>
>>> Make PCI dependent functions ([alloc|free]_consistent() in
>>> 'vme.c') bridge specific. By removing the dependency of the
>>> VME bridge framework on PCI, this patch allows for addition of
>>> non-PCI based VME bridges.
>>>
>>
>> I like t
Hi Martyn,
> > Make PCI dependent functions ([alloc|free]_consistent() in
> > 'vme.c') bridge specific. By removing the dependency of the
> > VME bridge framework on PCI, this patch allows for addition of
> > non-PCI based VME bridges.
> >
>
> I like the approach, I think I agree with Dan, I'd r
> I like the approach, I think I agree with Dan, I'd rather see the locking
> inside the function for now.
Great! I'll put the locking into the function and resend the patch.
--
/manohar
___
devel mailing list
devel@linuxdriverproject.org
http://driverd
On 01/08/11 11:20, Manohar Vanga wrote:
> Make PCI dependent functions ([alloc|free]_consistent() in
> 'vme.c') bridge specific. By removing the dependency of the
> VME bridge framework on PCI, this patch allows for addition of
> non-PCI based VME bridges.
>
I like the approach, I think I agree w
On 01/08/11 11:20, Manohar Vanga wrote:
> From: Emilio G. Cota
>
> In a configuration with several bridges, each bridge is
> assigned a certain bus number depending on the order in which
> bridge modules are loaded. This can complicate multi-bridge
> installations because the bus numbers will dep
On 08/01/2011 01:54 PM, Dan Carpenter wrote:
On Thu, Jul 14, 2011 at 02:29:14PM -0700, Franky Lin wrote:
From: Arend van Spriel
The semaphore proto_sem has been replaced with mutex proto_block
which lock certain code paths for one thread.
This one doesn't apply any more after the 3.1 merge wi
Hi Martyn,
> If your doing vme_slot_get, then there's also vme_lm_get, vme_master_get and
> vme_slave_get.
>
> Doing just this would then lead to more inconsistency in the naming and
> wouldn't even get rid of all the functions using the *_get naming convention.
I can simply change those as well
On 01/08/11 11:20, Manohar Vanga wrote:
> Functions following the naming format of *_get and *_put are used
> for reference counting. Rename the slot_get functions to get_slot
> to prevent such confusion in the meaning.
>
If your doing vme_slot_get, then there's also vme_lm_get, vme_master_get an
Hi Dan,
> The user wouldn't know which driver is printing the error.
> ...
> Could probably be improved as well.
Thanks! I have added the bridge name to the output here.
P.S. Should I send this patch immediately or wait till I have some
feedback on the others and resend them all at once?
--
/ma
On Mon, Aug 01, 2011 at 02:10:00PM +0300, Dan Carpenter wrote:
> On Mon, Aug 01, 2011 at 12:20:47PM +0200, Manohar Vanga wrote:
> > -static int vme_alloc_bus_num(void)
> > +/* call with vme_bus_num_mtx held */
>
> Why move the lock outside the function?
>
> > +static int __vme_alloc_bus_num(int b
On Thu, Jul 14, 2011 at 02:29:14PM -0700, Franky Lin wrote:
> From: Arend van Spriel
>
> The semaphore proto_sem has been replaced with mutex proto_block
> which lock certain code paths for one thread.
>
This one doesn't apply any more after the 3.1 merge window.
It was modified in 1380516599
On Mon, Aug 01, 2011 at 12:20:48PM +0200, Manohar Vanga wrote:
> if (bridge->parent == NULL) {
> printk(KERN_ERR "Dev entry NULL\n");
The user wouldn't know which driver is printing the error.
> return NULL;
> }
> - pdev = container_of(bridge->parent, s
On Mon, Aug 01, 2011 at 12:20:47PM +0200, Manohar Vanga wrote:
> -static int vme_alloc_bus_num(void)
> +/* call with vme_bus_num_mtx held */
Why move the lock outside the function?
> +static int __vme_alloc_bus_num(int bus_num)
> {
regards,
dan carpenter
___
On 01/08/11 11:20, Manohar Vanga wrote:
> Signed-off-by: Manohar Vanga
Acked-by: Martyn Welch
> ---
> drivers/staging/vme/devices/vme_user.c |4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/vme/devices/vme_user.c
> b/drivers/staging/vme/devices
For jumper based boards (non VME64x), there is no mechanism
for detecting the card that is plugged into a specific slot. This
leads to issues in non-autodiscovery crates/cards when a card is
plugged into a slot that is "claimed" by a different driver. In
reality, there is no problem, but the driver
Instead of using a vanilla 'struct device' for VME devices, add new
'struct vme_dev'. Modifications have been made to the VME framework
API as well as all in-tree VME drivers.
The new vme_dev structure has the following advantages from the
current model used by the driver:
* Driver functions
Functions following the naming format of *_get and *_put are used
for reference counting. Rename the slot_get functions to get_slot
to prevent such confusion in the meaning.
Signed-off-by: Manohar Vanga
---
drivers/staging/vme/bridges/vme_ca91cx42.c |8
drivers/staging/vme/bridges/v
This patch adds functions that allow for reference counting
bridge modules. The patch introduces the functions
'vme_bridge_get()' and 'vme_bridge_put()'.
This patch is based on the changes introduced by Emilio G. Cota
in the patch:
https://lkml.org/lkml/2010/10/25/492
Signed-off-by: Manohar
This patch adds a list which keeps track of all registered VME
buses. This is required for adding refcounting later to bridge
modules, something that is not currently implemented.
This is based on the changes introduced by Emilio G. Cota in the
patch:
https://lkml.org/lkml/2010/10/25/486
Sig
Make PCI dependent functions ([alloc|free]_consistent() in
'vme.c') bridge specific. By removing the dependency of the
VME bridge framework on PCI, this patch allows for addition of
non-PCI based VME bridges.
Signed-off-by: Manohar Vanga
---
drivers/staging/vme/bridges/vme_ca91cx42.c | 24
From: Emilio G. Cota
In a configuration with several bridges, each bridge is
assigned a certain bus number depending on the order in which
bridge modules are loaded. This can complicate multi-bridge
installations because the bus numbers will depend on the load
order of the bridges.
This patch al
Signed-off-by: Manohar Vanga
---
drivers/staging/vme/devices/vme_user.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/vme/devices/vme_user.c
b/drivers/staging/vme/devices/vme_user.c
index 91d2cc7..3cbeb2a 100644
--- a/drivers/staging/vme/devices/vme_
A little background: I work at CERN in the device drivers section and
we have a lot of VME crates we use in the accelerator controls. We have
been using an in-house driver for some time now and want to slowly port
our existing device drivers over to the kernel driver.
This set of patches adds mult
On 07/30/11 09:45, Dan Carpenter wrote:
> This code was cut and pasted in several places. It's missing some
> unlocks on error.
oops. Thanks Dan.
>
> Signed-off-by: Dan Carpenter
Acked-by: Jonathan Cameron
>
> diff --git a/drivers/staging/iio/accel/adis16203_core.c
> b/drivers/staging/iio/acc
Fix too long lines in cx25821-audio.h and cx25821-core.c
Fix wrong brace placement it cx25821-cards.c, cx25821-core.c,
and cx25821-i2c.c
Use DEFINE_PCI_DEVICE_TABLE for cx25821_pci_tbl.
Move EXPORT_SYMBOL(cx25821_set_gpiopin_direction) to the right place.
Delete file cx25821-gpio.h as it is not use
33 matches
Mail list logo
