Re: [PATCH v3] Add device ID for Bluetooth on Macbook Pro 2012
On 18 August 2012 01:21, Henrik Rydberg wrote: > Hi Daniel, > >> Add the device ID for supporting the Macbook Pro 2012 'MacBookPro10,1'. >> The bluetooth device presents itself as: >> >> T: Bus=02 Lev=04 Prnt=04 Port=02 Cnt=03 Dev#= 8 Spd=12 MxCh= 0 >> D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 >> P: Vendor=05ac ProdID=8286 Rev=00.86 >> S: Manufacturer=Apple Inc. >> S: Product=Bluetooth USB Host Controller >> C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA >> I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) >> I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) >> I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) >> I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) >> >> Patch originally written and tested by clipcarl (forums.opensuse.org). >> >> Signed-off-by: Daniel J Blueman >> Signed-off-by: Henrik Rydberg >> --- > > I did not sign off this patch. The author is different, the subject > and wording is different, the credits are different. It looks like you > sent a patch which I subsequently added my SOB to, but that is not the > case. Please do not do that. > > If you meant to add your blessing somehow, or if you are the unknown > original author, adding an originally-by or tested-by or reviewed-by > would be more appropriate. > > Either way, the patch is moot; With Gustavo's commit d81a5d195, the > plan is to support this machine via a more generic device entry. Apologies; my intent was to update your patch [1] description with the output Marcel asked (as I have the hardware), but I clarified the subject and description also. The actual content is identical of course, but I should have cited your post. Great to know Gustavo has added support. Thanks! Daniel [1] https://lkml.org/lkml/2012/7/10/150 -- Daniel J Blueman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add MSI support for SDHCI PCI hosts
Hi Philip,
The interrupt could be from another source, though Message Signalled
Interrupts are a PCI (and variants) only feature at present. I'm happy
to split the patch and/or make the module param specific to sdhci-pci.
Let's see what the maintainers prefer...Chris?
Dan
On 18 August 2012 00:35, Philip Rakity wrote:
>
> The interrupt source could be from a non-pci device. Say a gpio or whatever.
> Does it make sense to break this patch into two patches ?
>
> On Aug 17, 2012, at 2:14 AM, Daniel J Blueman wrote:
>
>> Allow module parameter 'enable_msi' to request an MSI interrupt for
>> hosts where available (presently PCI). Useful as a workaround on
>> platforms where the legacy interrupt is broken.
>>
>> Signed-off-by: Daniel J Blueman
>> ---
>> drivers/mmc/host/sdhci-pci.c | 30 ++
>> drivers/mmc/host/sdhci.c | 23 +++
>> drivers/mmc/host/sdhci.h |2 ++
>> 3 files changed, 55 insertions(+)
>>
>> diff --git a/drivers/mmc/host/sdhci-pci.c b/drivers/mmc/host/sdhci-pci.c
>> index 504da71..fbde589 100644
>> --- a/drivers/mmc/host/sdhci-pci.c
>> +++ b/drivers/mmc/host/sdhci-pci.c
>> @@ -934,6 +934,34 @@ static int sdhci_pci_enable_dma(struct sdhci_host *host)
>> return 0;
>> }
>>
>> +static int sdhci_pci_enable_msi(struct sdhci_host *host)
>> +{
>> + struct sdhci_pci_slot *slot;
>> + struct pci_dev *pdev;
>> + int ret;
>> +
>> + slot = sdhci_priv(host);
>> + pdev = slot->chip->pdev;
>> +
>> + ret = pci_enable_msi(pdev);
>> + if (ret)
>> + return ret;
>> +
>> + host->irq = pdev->irq;
>> + return 0;
>> +}
>> +
>> +static void sdhci_pci_disable_msi(struct sdhci_host *host)
>> +{
>> + struct sdhci_pci_slot *slot;
>> + struct pci_dev *pdev;
>> +
>> + slot = sdhci_priv(host);
>> + pdev = slot->chip->pdev;
>> +
>> + pci_disable_msi(pdev);
>> +}
>> +
>> static int sdhci_pci_8bit_width(struct sdhci_host *host, int width)
>> {
>> u8 ctrl;
>> @@ -976,6 +1004,8 @@ static void sdhci_pci_hw_reset(struct sdhci_host *host)
>>
>> static struct sdhci_ops sdhci_pci_ops = {
>> .enable_dma = sdhci_pci_enable_dma,
>> + .enable_msi = sdhci_pci_enable_msi,
>> + .disable_msi= sdhci_pci_disable_msi,
>> .platform_8bit_width= sdhci_pci_8bit_width,
>> .hw_reset = sdhci_pci_hw_reset,
>> };
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index 9a11dc3..9fa2180 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -45,6 +45,7 @@
>>
>> static unsigned int debug_quirks = 0;
>> static unsigned int debug_quirks2;
>> +static bool enable_msi;
>>
>> static void sdhci_finish_data(struct sdhci_host *);
>>
>> @@ -2433,6 +2434,9 @@ int sdhci_suspend_host(struct sdhci_host *host)
>>
>> free_irq(host->irq, host);
>>
>> + if (host->ops->disable_msi && enable_msi)
>> + host->ops->disable_msi(host);
>> +
>> return ret;
>> }
>>
>> @@ -2447,6 +2451,12 @@ int sdhci_resume_host(struct sdhci_host *host)
>> host->ops->enable_dma(host);
>> }
>>
>> + if (host->ops->enable_msi && enable_msi) {
>> + ret = host->ops->enable_msi(host);
>> + if (ret)
>> + return ret;
>> + }
>> +
>> ret = request_irq(host->irq, sdhci_irq, IRQF_SHARED,
>> mmc_hostname(host->mmc), host);
>> if (ret)
>> @@ -3024,6 +3034,12 @@ int sdhci_add_host(struct sdhci_host *host)
>> host->tuning_timer.function = sdhci_tuning_timer;
>> }
>>
>> + if (host->ops->enable_msi && enable_msi) {
>> + ret = host->ops->enable_msi(host);
>> + if (ret)
>> + return ret;
>> + }
>> +
>> ret = request_irq(host->irq, sdhci_irq, IRQF_SHARED,
>> mmc_hostname(mmc), host);
>> if (ret) {
>> @@ -3071,6 +3087,8 @@ int sdhci_add_host(struct sdhci_host *host)
>> reset:
>> sdhci_reset(host, SDHCI_RESET_ALL);
>> free_irq(host->irq, host);
>> + if (host->ops->disable_msi && enable_msi)
>> + host->ops->disable_msi(host);
>> #endif
>> untasklet:
>> tasklet_kill(>card_tasklet);
>> @@ -3114,6 +3132,9 @@ void sdhci_remove_host(struct sdhci_host *host, int
>> dead)
>>
>> free_irq(host->irq, host);
>>
>> + if (host->ops->disable_msi && enable_msi)
>> + host->ops->disable_msi(host);
>> +
>> del_timer_sync(>timer);
>>
>> tasklet_kill(>card_tasklet);
>> @@ -3162,6 +3183,7 @@ module_exit(sdhci_drv_exit);
>>
>> module_param(debug_quirks, uint, 0444);
>> module_param(debug_quirks2, uint, 0444);
>> +module_param(enable_msi, bool, 0444);
>>
>> MODULE_AUTHOR("Pierre Ossman ");
>> MODULE_DESCRIPTION("Secure Digital Host Controller Interface core driver");
>> @@ -3169,3 +3191,4 @@ MODULE_LICENSE("GPL");
>>
>> MODULE_PARM_DESC(debug_quirks, "Force certain quirks.");
>>
Re: lockdep warning on rt_mutex_lock()
On Fri, Aug 17, 2012 at 07:44:37AM -0700, Paul E. McKenney wrote: > On Fri, Aug 17, 2012 at 10:02:40PM +0800, Fengguang Wu wrote: > > On Fri, Aug 17, 2012 at 06:43:28AM -0700, Paul E. McKenney wrote: > > > On Fri, Aug 17, 2012 at 06:06:35PM +0800, Fengguang Wu wrote: > > > > Greetings, > > > > > > > > FYI, a lockdep warning: > > > > > > Certainly looks problematic! > > > > > > Any hint as to what version of the kernel produced this splat? > > > (Yes, lazy of me to ask, I know, but I am not seeing it in my testing.) > > > > It happens on both 3.5.0 and 3.6-rc1. Will bisect (try older kernels) help? > > Bisect is handy for me :) > > Bisection would be very welcome!!! ;-) The bisect result is... commit 9e571a82f0cb205a65a0ea41657f19f22b7fabb8 Author: Paul E. McKenney Date: Thu Sep 30 21:26:52 2010 -0700 rcu: add tracing for TINY_RCU and TINY_PREEMPT_RCU Add tracing for the tiny RCU implementations, including statistics on boosting in the case of TINY_PREEMPT_RCU and RCU_BOOST. Signed-off-by: Paul E. McKenney Signed-off-by: Paul E. McKenney Thanks, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Repeated fork() causes SLAB to grow without bound
On 08/18/2012 12:07 AM, Daniel Forrest wrote: I was being careful since I wasn't certain about the locking. Does the test need to be protected by "lock_anon_vma_root"? That's why I chose the overhead of the possible wasted "anon_vma_chain_alloc". The function anon_vma_clone is being called from fork(). When running fork(), the kernel holds the mm->mmap_sem for write, which prevents page faults by the parent process. This means if the anon_vma in question belongs to the parent process, no new pages will be added to it in this time. Likewise, if the anon_vma belonged to a grandparent process, any new pages instantiated in it will not be visible to the parent process, or to the newly created process. This means it is safe to skip the anon_vma. -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Repeated fork() causes SLAB to grow without bound
On Fri, Aug 17, 2012 at 11:46:18PM -0400, Rik van Riel wrote:
> On 08/17/2012 08:03 PM, Daniel Forrest wrote:
>
> >Based on your comments, I came up with the following patch. It boots
> >and the anon_vma/anon_vma_chain SLAB usage is stable, but I don't know
> >if I've overlooked something. I'm not a kernel hacker.
>
> The patch looks reasonable to me. There is one spot left
> for optimization, which I have pointed out below.
>
> Of course, that leaves the big question: do we want the
> overhead of having the atomic addition and decrement for
> every anonymous memory page, or is it easier to fix this
> issue in userspace?
>
> Given that malicious userspace could potentially run the
> system out of memory, without needing special privileges,
> and the OOM killer may not be able to reclaim it due to
> internal slab fragmentation, I guess this issue could be
> classified as a low impact denial of service vulnerability.
>
> Furthermore, there is already a fair amount of bookkeeping
> being done in the rmap code, so this patch is not likely
> to add a whole lot - some testing might be useful, though.
>
> >@@ -262,7 +264,10 @@ int anon_vma_clone(struct vm_area_struct
> > }
> > anon_vma = pavc->anon_vma;
> > root = lock_anon_vma_root(root, anon_vma);
> >-anon_vma_chain_link(dst, avc, anon_vma);
> >+if (!atomic_read(_vma->pagecount))
> >+anon_vma_chain_free(avc);
> >+else
> >+anon_vma_chain_link(dst, avc, anon_vma);
> > }
> > unlock_anon_vma_root(root);
> > return 0;
>
> In this function, you can do the test before the code block
> where we try to allocate an anon_vma chain.
>
> In other words:
>
> list_for_each_entry_reverse(.
> struct anon_vma *anon_vma;
>
> + if (!atomic_read(_vma->pagecount))
> + continue;
> +
> avc = anon_vma_chain_alloc(...
> if (unlikely(!avc)) {
>
> The rest looks good.
I was being careful since I wasn't certain about the locking. Does
the test need to be protected by "lock_anon_vma_root"? That's why I
chose the overhead of the possible wasted "anon_vma_chain_alloc".
--
Daniel K. Forrest Space Science and
dan.forr...@ssec.wisc.edu Engineering Center
(608) 890 - 0558University of Wisconsin, Madison
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2]block: handle merged discard request
> "Mike" == Mike Snitzer writes: Mike> Could be I've wasted a few hours by rebasing these patches... Mike> regardless, it would be great if you could share what your plans Mike> are. Heh, I worked on syncing my patch queue up to Jens' and James' trees this afternoon. But I didn't quite finish the block stuff, mainly due to some conflicts with a few topology changes I also have pending. I'll take a look at your series. Maybe I'll swap things around and put the topology changes on top instead of below. Leverage some of the work you did... -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Repeated fork() causes SLAB to grow without bound
On 08/17/2012 08:03 PM, Daniel Forrest wrote:
Based on your comments, I came up with the following patch. It boots
and the anon_vma/anon_vma_chain SLAB usage is stable, but I don't know
if I've overlooked something. I'm not a kernel hacker.
The patch looks reasonable to me. There is one spot left
for optimization, which I have pointed out below.
Of course, that leaves the big question: do we want the
overhead of having the atomic addition and decrement for
every anonymous memory page, or is it easier to fix this
issue in userspace?
Given that malicious userspace could potentially run the
system out of memory, without needing special privileges,
and the OOM killer may not be able to reclaim it due to
internal slab fragmentation, I guess this issue could be
classified as a low impact denial of service vulnerability.
Furthermore, there is already a fair amount of bookkeeping
being done in the rmap code, so this patch is not likely
to add a whole lot - some testing might be useful, though.
@@ -262,7 +264,10 @@ int anon_vma_clone(struct vm_area_struct
}
anon_vma = pavc->anon_vma;
root = lock_anon_vma_root(root, anon_vma);
- anon_vma_chain_link(dst, avc, anon_vma);
+ if (!atomic_read(_vma->pagecount))
+ anon_vma_chain_free(avc);
+ else
+ anon_vma_chain_link(dst, avc, anon_vma);
}
unlock_anon_vma_root(root);
return 0;
In this function, you can do the test before the code block
where we try to allocate an anon_vma chain.
In other words:
list_for_each_entry_reverse(.
struct anon_vma *anon_vma;
+ if (!atomic_read(_vma->pagecount))
+ continue;
+
avc = anon_vma_chain_alloc(...
if (unlikely(!avc)) {
The rest looks good.
--
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2]block: handle merged discard request
On Thu, Jun 21, 2012 at 11:46 PM, Martin K. Petersen wrote: >> "Christoph" == Christoph Hellwig writes: > >>> There are several additional commands in the pipeline where the 1:1 >>> mapping between DMA size and block range is invalid. I want to get >>> rid of the 1:1 assumption in general so we can handle any command >>> without these evil workarounds. > > Christoph> What's the progress on getting these issues sorted out? > > This has bitrotted for a while. I'll put it on my list. I should finally > have some bandwidth again next week... Hey Martin, I rebased (and fixed/tested) your writesame patches on v3.6-rc2 + jens' for-linus branch, the git tree is available here: https://github.com/snitm/linux/tree/writesame I've also made the updated patchset available here: http://people.redhat.com/msnitzer/patches/upstream/writesame/series.html Should the writesame patches come before any discard merge or 1:1 DMA and block range assumption fixes? NOTE (for others besides martin): http://people.redhat.com/msnitzer/patches/upstream/writesame/0001-block-Clean-up-merge-logic.patch removes all the discard merge hacks; I think it provides a clean baseline to then layer discard merge support back in -- but maybe that's a flawed strategy? Could be I've wasted a few hours by rebasing these patches... regardless, it would be great if you could share what your plans are. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 20/20] staging: comedi: adv_pci_dio: fix bug in 'detach'
The 'attach' function can fail between when the devpriv and
the comedi subdevices are allocated. If it does the 'detach'
will try to access unallocated memory when it goes thru the
subdevices.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/adv_pci_dio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/comedi/drivers/adv_pci_dio.c
b/drivers/staging/comedi/drivers/adv_pci_dio.c
index 4da0e7b..a4c1b13 100644
--- a/drivers/staging/comedi/drivers/adv_pci_dio.c
+++ b/drivers/staging/comedi/drivers/adv_pci_dio.c
@@ -1184,6 +1184,8 @@ static void pci_dio_detach(struct comedi_device *dev)
if (devpriv) {
if (devpriv->valid)
pci_dio_reset(dev);
+ }
+ if (dev->subdevices) {
for (i = 0; i < dev->n_subdevices; i++) {
s = dev->subdevices + i;
if (s->type == COMEDI_SUBD_DIO)
--
1.7.11
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 19/20] staging: comedi: adv_pci_dio: simplify the 'detach'
Currently the 'detach' function in this driver walks thru the
boardinfo in order to find the subdevice index for any sdio
subdevices in order to call the subdev_8255_cleanup(). Then
it goes thru all the subdevices to clean the s->private pointer.
All the sdio subdevices are unique in that the s->type is
COMEDI_SUBD_DIO. Use that to know when to call the cleanup
for the 8255 subdevice.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/adv_pci_dio.c | 27 +++
1 file changed, 3 insertions(+), 24 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adv_pci_dio.c
b/drivers/staging/comedi/drivers/adv_pci_dio.c
index 2c3dbf0..4da0e7b 100644
--- a/drivers/staging/comedi/drivers/adv_pci_dio.c
+++ b/drivers/staging/comedi/drivers/adv_pci_dio.c
@@ -1176,39 +1176,18 @@ static int pci_dio_attach_pci(struct comedi_device *dev,
static void pci_dio_detach(struct comedi_device *dev)
{
- const struct dio_boardtype *this_board = comedi_board(dev);
struct pci_dio_private *devpriv = dev->private;
struct pci_dev *pcidev = comedi_to_pci_dev(dev);
- int i, j;
struct comedi_subdevice *s;
- int subdev;
+ int i;
if (devpriv) {
if (devpriv->valid)
pci_dio_reset(dev);
- subdev = 0;
- for (i = 0; i < MAX_DI_SUBDEVS; i++) {
- if (this_board->sdi[i].chans)
- subdev++;
- }
- for (i = 0; i < MAX_DO_SUBDEVS; i++) {
- if (this_board->sdo[i].chans)
- subdev++;
- }
- for (i = 0; i < MAX_DIO_SUBDEVG; i++) {
- for (j = 0; j < this_board->sdio[i].regs; j++) {
- s = dev->subdevices + subdev;
- subdev_8255_cleanup(dev, s);
- subdev++;
- }
- }
- if (this_board->boardid.chans)
- subdev++;
- for (i = 0; i < MAX_8254_SUBDEVS; i++)
- if (this_board->s8254[i].chans)
- subdev++;
for (i = 0; i < dev->n_subdevices; i++) {
s = dev->subdevices + i;
+ if (s->type == COMEDI_SUBD_DIO)
+ subdev_8255_cleanup(dev, s);
s->private = NULL;
}
}
--
1.7.11
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 18/20] staging: comedi: adv_pci_dio: add the number of subdevices to the boardinfo
Instead of calculating the number of subdevices in the 'attach'
simply add the number to the boardinfo.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/adv_pci_dio.c | 39 +---
1 file changed, 18 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adv_pci_dio.c
b/drivers/staging/comedi/drivers/adv_pci_dio.c
index e535d31..2c3dbf0 100644
--- a/drivers/staging/comedi/drivers/adv_pci_dio.c
+++ b/drivers/staging/comedi/drivers/adv_pci_dio.c
@@ -241,6 +241,7 @@ struct dio_boardtype {
int device_id;
int main_pci_region;/* main I/O PCI region */
enum hw_cards_id cardtype;
+ int nsubdevs;
struct diosubd_data sdi[MAX_DI_SUBDEVS];/* DI chans */
struct diosubd_data sdo[MAX_DO_SUBDEVS];/* DO chans */
struct diosubd_data sdio[MAX_DIO_SUBDEVG]; /* DIO 8255 chans */
@@ -256,6 +257,7 @@ static const struct dio_boardtype boardtypes[] = {
.device_id = 0x1730,
.main_pci_region = PCIDIO_MAINREG,
.cardtype = TYPE_PCI1730,
+ .nsubdevs = 5,
.sdi[0] = { 16, PCI1730_DI, 2, 0, },
.sdi[1] = { 16, PCI1730_IDI, 2, 0, },
.sdo[0] = { 16, PCI1730_DO, 2, 0, },
@@ -268,6 +270,7 @@ static const struct dio_boardtype boardtypes[] = {
.device_id = 0x1733,
.main_pci_region = PCIDIO_MAINREG,
.cardtype = TYPE_PCI1733,
+ .nsubdevs = 2,
.sdi[1] = { 32, PCI1733_IDI, 4, 0, },
.boardid= { 4, PCI173x_BOARDID, 1, SDF_INTERNAL, },
.io_access = IO_8b,
@@ -277,6 +280,7 @@ static const struct dio_boardtype boardtypes[] = {
.device_id = 0x1734,
.main_pci_region = PCIDIO_MAINREG,
.cardtype = TYPE_PCI1734,
+ .nsubdevs = 2,
.sdo[1] = { 32, PCI1734_IDO, 4, 0, },
.boardid= { 4, PCI173x_BOARDID, 1, SDF_INTERNAL, },
.io_access = IO_8b,
@@ -286,6 +290,7 @@ static const struct dio_boardtype boardtypes[] = {
.device_id = 0x1735,
.main_pci_region = PCIDIO_MAINREG,
.cardtype = TYPE_PCI1735,
+ .nsubdevs = 4,
.sdi[0] = { 32, PCI1735_DI, 4, 0, },
.sdo[0] = { 32, PCI1735_DO, 4, 0, },
.boardid= { 4, PCI1735_BOARDID, 1, SDF_INTERNAL, },
@@ -297,6 +302,7 @@ static const struct dio_boardtype boardtypes[] = {
.device_id = 0x1736,
.main_pci_region = PCI1736_MAINREG,
.cardtype = TYPE_PCI1736,
+ .nsubdevs = 3,
.sdi[1] = { 16, PCI1736_IDI, 2, 0, },
.sdo[1] = { 16, PCI1736_IDO, 2, 0, },
.boardid= { 4, PCI1736_BOARDID, 1, SDF_INTERNAL, },
@@ -307,6 +313,7 @@ static const struct dio_boardtype boardtypes[] = {
.device_id = 0x1739,
.main_pci_region = PCIDIO_MAINREG,
.cardtype = TYPE_PCI1739,
+ .nsubdevs = 2,
.sdio[0]= { 48, PCI1739_DIO, 2, 0, },
.io_access = IO_8b,
}, {
@@ -315,6 +322,7 @@ static const struct dio_boardtype boardtypes[] = {
.device_id = 0x1750,
.main_pci_region = PCIDIO_MAINREG,
.cardtype = TYPE_PCI1750,
+ .nsubdevs = 2,
.sdi[1] = { 16, PCI1750_IDI, 2, 0, },
.sdo[1] = { 16, PCI1750_IDO, 2, 0, },
.io_access = IO_8b,
@@ -324,6 +332,7 @@ static const struct dio_boardtype boardtypes[] = {
.device_id = 0x1751,
.main_pci_region = PCIDIO_MAINREG,
.cardtype = TYPE_PCI1751,
+ .nsubdevs = 3,
.sdio[0]= { 48, PCI1751_DIO, 2, 0, },
.s8254[0] = { 3, PCI1751_CNT, 1, 0, },
.io_access = IO_8b,
@@ -333,6 +342,7 @@ static const struct dio_boardtype boardtypes[] = {
.device_id = 0x1752,
.main_pci_region = PCIDIO_MAINREG,
.cardtype = TYPE_PCI1752,
+ .nsubdevs = 3,
.sdo[0] = { 32, PCI1752_IDO, 2, 0, },
.sdo[1] = { 32, PCI1752_IDO2, 2, 0, },
.boardid= { 4, PCI175x_BOARDID, 1, SDF_INTERNAL, },
@@ -343,6 +353,7 @@ static const struct dio_boardtype boardtypes[] = {
.device_id = 0x1753,
.main_pci_region = PCIDIO_MAINREG,
.cardtype = TYPE_PCI1753,
+
[PATCH 17/20] staging: comedi: adv_pci_dio: remove '0' boardinfo data
Remove all the boardinfo data that is simply '0'.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/adv_pci_dio.c | 84
1 file changed, 84 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adv_pci_dio.c
b/drivers/staging/comedi/drivers/adv_pci_dio.c
index 0d1b441..e535d31 100644
--- a/drivers/staging/comedi/drivers/adv_pci_dio.c
+++ b/drivers/staging/comedi/drivers/adv_pci_dio.c
@@ -260,10 +260,7 @@ static const struct dio_boardtype boardtypes[] = {
.sdi[1] = { 16, PCI1730_IDI, 2, 0, },
.sdo[0] = { 16, PCI1730_DO, 2, 0, },
.sdo[1] = { 16, PCI1730_IDO, 2, 0, },
- .sdio[0]= { 0, 0, 0, 0, },
- .sdio[1]= { 0, 0, 0, 0, },
.boardid= { 4, PCI173x_BOARDID, 1, SDF_INTERNAL, },
- .s8254[0] = { 0, 0, 0, 0, },
.io_access = IO_8b,
}, {
.name = "pci1733",
@@ -271,14 +268,8 @@ static const struct dio_boardtype boardtypes[] = {
.device_id = 0x1733,
.main_pci_region = PCIDIO_MAINREG,
.cardtype = TYPE_PCI1733,
- .sdi[0] = { 0, 0, 0, 0, },
.sdi[1] = { 32, PCI1733_IDI, 4, 0, },
- .sdo[0] = { 0, 0, 0, 0, },
- .sdo[1] = { 0, 0, 0, 0, },
- .sdio[0]= { 0, 0, 0, 0, },
- .sdio[1]= { 0, 0, 0, 0, },
.boardid= { 4, PCI173x_BOARDID, 1, SDF_INTERNAL, },
- .s8254[0] = { 0, 0, 0, 0, },
.io_access = IO_8b,
}, {
.name = "pci1734",
@@ -286,14 +277,8 @@ static const struct dio_boardtype boardtypes[] = {
.device_id = 0x1734,
.main_pci_region = PCIDIO_MAINREG,
.cardtype = TYPE_PCI1734,
- .sdi[0] = { 0, 0, 0, 0, },
- .sdi[1] = { 0, 0, 0, 0, },
- .sdo[0] = { 0, 0, 0, 0, },
.sdo[1] = { 32, PCI1734_IDO, 4, 0, },
- .sdio[0]= { 0, 0, 0, 0 },
- .sdio[1]= { 0, 0, 0, 0 },
.boardid= { 4, PCI173x_BOARDID, 1, SDF_INTERNAL, },
- .s8254[0] = { 0, 0, 0, 0, },
.io_access = IO_8b,
}, {
.name = "pci1735",
@@ -302,11 +287,7 @@ static const struct dio_boardtype boardtypes[] = {
.main_pci_region = PCIDIO_MAINREG,
.cardtype = TYPE_PCI1735,
.sdi[0] = { 32, PCI1735_DI, 4, 0, },
- .sdi[1] = { 0, 0, 0, 0, },
.sdo[0] = { 32, PCI1735_DO, 4, 0, },
- .sdo[1] = { 0, 0, 0, 0, },
- .sdio[0]= { 0, 0, 0, 0, },
- .sdio[1]= { 0, 0, 0, 0, },
.boardid= { 4, PCI1735_BOARDID, 1, SDF_INTERNAL, },
.s8254[0] = { 3, PCI1735_C8254, 1, 0, },
.io_access = IO_8b,
@@ -316,14 +297,9 @@ static const struct dio_boardtype boardtypes[] = {
.device_id = 0x1736,
.main_pci_region = PCI1736_MAINREG,
.cardtype = TYPE_PCI1736,
- .sdi[0] = { 0, 0, 0, 0, },
.sdi[1] = { 16, PCI1736_IDI, 2, 0, },
- .sdo[0] = { 0, 0, 0, 0, },
.sdo[1] = { 16, PCI1736_IDO, 2, 0, },
- .sdio[0]= { 0, 0, 0, 0, },
- .sdio[1]= { 0, 0, 0, 0, },
.boardid= { 4, PCI1736_BOARDID, 1, SDF_INTERNAL, },
- .s8254[0] = { 0, 0, 0, 0, },
.io_access = IO_8b,
}, {
.name = "pci1739",
@@ -331,14 +307,7 @@ static const struct dio_boardtype boardtypes[] = {
.device_id = 0x1739,
.main_pci_region = PCIDIO_MAINREG,
.cardtype = TYPE_PCI1739,
- .sdi[0] = { 0, 0, 0, 0, },
- .sdi[1] = { 0, 0, 0, 0, },
- .sdo[0] = { 0, 0, 0, 0, },
- .sdo[1] = { 0, 0, 0, 0, },
.sdio[0]= { 48, PCI1739_DIO, 2, 0, },
- .sdio[1]= { 0, 0, 0, 0, },
- .boardid= { 0, 0, 0, 0, },
- .s8254[0] = { 0, 0, 0, 0, },
.io_access = IO_8b,
}, {
.name = "pci1750",
@@ -346,14 +315,8 @@ static const struct dio_boardtype boardtypes[] = {
.device_id = 0x1750,
.main_pci_region = PCIDIO_MAINREG,
.cardtype = TYPE_PCI1750,
- .sdi[0] =
[PATCH 16/20] staging: comedi: adv_pci_dio: convert boardinfo initialization to C99 format
Convert the boardinfo initialization to C99 format to make it
less error prone.
The struct diosubd_data information is not converted to C99 format
yet because some of it will be removed.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/adv_pci_dio.c | 347 ++-
1 file changed, 227 insertions(+), 120 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adv_pci_dio.c
b/drivers/staging/comedi/drivers/adv_pci_dio.c
index 36b7c8d..0d1b441 100644
--- a/drivers/staging/comedi/drivers/adv_pci_dio.c
+++ b/drivers/staging/comedi/drivers/adv_pci_dio.c
@@ -250,126 +250,233 @@ struct dio_boardtype {
};
static const struct dio_boardtype boardtypes[] = {
- {"pci1730", PCI_VENDOR_ID_ADVANTECH, 0x1730, PCIDIO_MAINREG,
-TYPE_PCI1730,
-{ {16, PCI1730_DI, 2, 0}, {16, PCI1730_IDI, 2, 0} },
-{ {16, PCI1730_DO, 2, 0}, {16, PCI1730_IDO, 2, 0} },
-{ {0, 0, 0, 0}, {0, 0, 0, 0} },
-{4, PCI173x_BOARDID, 1, SDF_INTERNAL},
-{ {0, 0, 0, 0} },
-IO_8b},
- {"pci1733", PCI_VENDOR_ID_ADVANTECH, 0x1733, PCIDIO_MAINREG,
-TYPE_PCI1733,
-{ {0, 0, 0, 0}, {32, PCI1733_IDI, 4, 0} },
-{ {0, 0, 0, 0}, {0, 0, 0, 0} },
-{ {0, 0, 0, 0}, {0, 0, 0, 0} },
-{4, PCI173x_BOARDID, 1, SDF_INTERNAL},
-{ {0, 0, 0, 0} },
-IO_8b},
- {"pci1734", PCI_VENDOR_ID_ADVANTECH, 0x1734, PCIDIO_MAINREG,
-TYPE_PCI1734,
-{ {0, 0, 0, 0}, {0, 0, 0, 0} },
-{ {0, 0, 0, 0}, {32, PCI1734_IDO, 4, 0} },
-{ {0, 0, 0, 0}, {0, 0, 0, 0} },
-{4, PCI173x_BOARDID, 1, SDF_INTERNAL},
-{ {0, 0, 0, 0} },
-IO_8b},
- {"pci1735", PCI_VENDOR_ID_ADVANTECH, 0x1735, PCIDIO_MAINREG,
-TYPE_PCI1735,
-{ {32, PCI1735_DI, 4, 0}, {0, 0, 0, 0} },
-{ {32, PCI1735_DO, 4, 0}, {0, 0, 0, 0} },
-{ {0, 0, 0, 0}, {0, 0, 0, 0} },
-{ 4, PCI1735_BOARDID, 1, SDF_INTERNAL},
-{ {3, PCI1735_C8254, 1, 0} },
-IO_8b},
- {"pci1736", PCI_VENDOR_ID_ADVANTECH, 0x1736, PCI1736_MAINREG,
-TYPE_PCI1736,
-{ {0, 0, 0, 0}, {16, PCI1736_IDI, 2, 0} },
-{ {0, 0, 0, 0}, {16, PCI1736_IDO, 2, 0} },
-{ {0, 0, 0, 0}, {0, 0, 0, 0} },
-{4, PCI1736_BOARDID, 1, SDF_INTERNAL},
-{ {0, 0, 0, 0} },
-IO_8b},
- {"pci1739", PCI_VENDOR_ID_ADVANTECH, 0x1739, PCIDIO_MAINREG,
-TYPE_PCI1739,
-{ {0, 0, 0, 0}, {0, 0, 0, 0} },
-{ {0, 0, 0, 0}, {0, 0, 0, 0} },
-{ {48, PCI1739_DIO, 2, 0}, {0, 0, 0, 0} },
-{0, 0, 0, 0},
-{ {0, 0, 0, 0} },
-IO_8b},
- {"pci1750", PCI_VENDOR_ID_ADVANTECH, 0x1750, PCIDIO_MAINREG,
-TYPE_PCI1750,
-{ {0, 0, 0, 0}, {16, PCI1750_IDI, 2, 0} },
-{ {0, 0, 0, 0}, {16, PCI1750_IDO, 2, 0} },
-{ {0, 0, 0, 0}, {0, 0, 0, 0} },
-{0, 0, 0, 0},
-{ {0, 0, 0, 0} },
-IO_8b},
- {"pci1751", PCI_VENDOR_ID_ADVANTECH, 0x1751, PCIDIO_MAINREG,
-TYPE_PCI1751,
-{ {0, 0, 0, 0}, {0, 0, 0, 0} },
-{ {0, 0, 0, 0}, {0, 0, 0, 0} },
-{ {48, PCI1751_DIO, 2, 0}, {0, 0, 0, 0} },
-{0, 0, 0, 0},
-{ {3, PCI1751_CNT, 1, 0} },
-IO_8b},
- {"pci1752", PCI_VENDOR_ID_ADVANTECH, 0x1752, PCIDIO_MAINREG,
-TYPE_PCI1752,
-{ {0, 0, 0, 0}, {0, 0, 0, 0} },
-{ {32, PCI1752_IDO, 2, 0}, {32, PCI1752_IDO2, 2, 0} },
-{ {0, 0, 0, 0}, {0, 0, 0, 0} },
-{4, PCI175x_BOARDID, 1, SDF_INTERNAL},
-{ {0, 0, 0, 0} },
-IO_16b},
- {"pci1753", PCI_VENDOR_ID_ADVANTECH, 0x1753, PCIDIO_MAINREG,
-TYPE_PCI1753,
-{ {0, 0, 0, 0}, {0, 0, 0, 0} },
-{ {0, 0, 0, 0}, {0, 0, 0, 0} },
-{ {96, PCI1753_DIO, 4, 0}, {0, 0, 0, 0} },
-{0, 0, 0, 0},
-{ {0, 0, 0, 0} },
-IO_8b},
- {"pci1753e", PCI_VENDOR_ID_ADVANTECH, 0x1753, PCIDIO_MAINREG,
-TYPE_PCI1753E,
-{ {0, 0, 0, 0}, {0, 0, 0, 0} },
-{ {0, 0, 0, 0}, {0, 0, 0, 0} },
-{ {96, PCI1753_DIO, 4, 0}, {96, PCI1753E_DIO, 4, 0} },
-{0, 0, 0, 0},
-{ {0, 0, 0, 0} },
-IO_8b},
- {"pci1754", PCI_VENDOR_ID_ADVANTECH, 0x1754, PCIDIO_MAINREG,
-TYPE_PCI1754,
-{ {32, PCI1754_IDI, 2, 0}, {32, PCI1754_IDI2, 2, 0} },
-{ {0, 0, 0, 0}, {0, 0, 0, 0} },
-{ {0, 0, 0, 0}, {0, 0, 0, 0} },
-{4, PCI175x_BOARDID, 1, SDF_INTERNAL},
-{ {0, 0, 0, 0} },
-IO_16b},
- {"pci1756", PCI_VENDOR_ID_ADVANTECH, 0x1756, PCIDIO_MAINREG,
-TYPE_PCI1756,
-{ {0, 0, 0, 0}, {32, PCI1756_IDI, 2, 0} },
-{ {0, 0, 0, 0}, {32, PCI1756_IDO, 2, 0} },
-{ {0, 0, 0, 0}, {0, 0, 0, 0} },
-{4, PCI175x_BOARDID, 1, SDF_INTERNAL},
-{ {0, 0, 0, 0} },
-IO_16b},
- {"pci1760", PCI_VENDOR_ID_ADVANTECH, 0x1760, 0,
-TYPE_PCI1760,
-{ {0, 0, 0, 0}, {0,
[PATCH 15/20] staging: comedi: adv_pci_dio: use attach_pci callback
Convert this PCI driver to use the comedi PCI auto config attach
mechanism by adding an 'attach_pci' callback function. Since the
driver does not require any external configuration options, and
the legacy 'attach' callback is now optional, remove it.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/adv_pci_dio.c | 61 ++--
1 file changed, 22 insertions(+), 39 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adv_pci_dio.c
b/drivers/staging/comedi/drivers/adv_pci_dio.c
index 97fc6b8..36b7c8d 100644
--- a/drivers/staging/comedi/drivers/adv_pci_dio.c
+++ b/drivers/staging/comedi/drivers/adv_pci_dio.c
@@ -913,8 +913,7 @@ static int pci_dio_reset(struct comedi_device *dev)
/*
==
*/
-static int pci1760_attach(struct comedi_device *dev,
- struct comedi_devconfig *it)
+static int pci1760_attach(struct comedi_device *dev)
{
struct comedi_subdevice *s;
int subdev = 0;
@@ -1042,60 +1041,45 @@ static int pci_dio_add_8254(struct comedi_device *dev,
return 0;
}
-static struct pci_dev *pci_dio_find_pci_dev(struct comedi_device *dev,
- struct comedi_devconfig *it)
+static const void *pci_dio_find_boardinfo(struct comedi_device *dev,
+ struct pci_dev *pcidev)
{
- struct pci_dev *pcidev = NULL;
- int bus = it->options[0];
- int slot = it->options[1];
+ const struct dio_boardtype *this_board;
int i;
- for_each_pci_dev(pcidev) {
- if (bus || slot) {
- if (bus != pcidev->bus->number ||
- slot != PCI_SLOT(pcidev->devfn))
- continue;
- }
- for (i = 0; i < ARRAY_SIZE(boardtypes); ++i) {
- if (boardtypes[i].vendor_id != pcidev->vendor)
- continue;
- if (boardtypes[i].device_id != pcidev->device)
- continue;
- dev->board_ptr = boardtypes + i;
- return pcidev;
- }
+ for (i = 0; i < ARRAY_SIZE(boardtypes); ++i) {
+ this_board = [i];
+ if (this_board->vendor_id == pcidev->vendor &&
+ this_board->device_id == pcidev->device)
+ return this_board;
}
- dev_err(dev->class_dev,
- "No supported board found! (req. bus %d, slot %d)\n",
- bus, slot);
return NULL;
}
-static int pci_dio_attach(struct comedi_device *dev,
- struct comedi_devconfig *it)
+static int pci_dio_attach_pci(struct comedi_device *dev,
+ struct pci_dev *pcidev)
{
const struct dio_boardtype *this_board;
struct pci_dio_private *devpriv;
- struct pci_dev *pcidev;
struct comedi_subdevice *s;
int ret, subdev, n_subdevices, i, j;
+ comedi_set_hw_dev(dev, >dev);
+
+ this_board = pci_dio_find_boardinfo(dev, pcidev);
+ if (!this_board)
+ return -ENODEV;
+ dev->board_ptr = this_board;
+ dev->board_name = this_board->name;
+
ret = alloc_private(dev, sizeof(*devpriv));
if (ret < 0)
return ret;
devpriv = dev->private;
- pcidev = pci_dio_find_pci_dev(dev, it);
- if (!pcidev)
- return -EIO;
- comedi_set_hw_dev(dev, >dev);
- this_board = comedi_board(dev);
- dev->board_name = this_board->name;
-
ret = comedi_pci_enable(pcidev, dev->board_name);
if (ret)
return ret;
-
dev->iobase = pci_resource_start(pcidev, this_board->main_pci_region);
if (this_board->cardtype == TYPE_PCI1760) {
@@ -1161,7 +1145,7 @@ static int pci_dio_attach(struct comedi_device *dev,
}
if (this_board->cardtype == TYPE_PCI1760)
- pci1760_attach(dev, it);
+ pci1760_attach(dev);
devpriv->valid = 1;
@@ -1211,15 +1195,14 @@ static void pci_dio_detach(struct comedi_device *dev)
if (pcidev) {
if (dev->iobase)
comedi_pci_disable(pcidev);
- pci_dev_put(pcidev);
}
}
static struct comedi_driver adv_pci_dio_driver = {
.driver_name= "adv_pci_dio",
.module = THIS_MODULE,
- .attach = pci_dio_attach,
- .detach = pci_dio_detach
+ .attach_pci = pci_dio_attach_pci,
+ .detach = pci_dio_detach,
};
static int __devinit adv_pci_dio_pci_probe(struct pci_dev *dev,
--
1.7.11
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
[PATCH 14/20] staging: comedi: adv_pci_dio: remove devpriv and this_board macros
These macros rely on a local variable having a specific name. Remove
them and use the comedi_board() helper to get the this_board pointer.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/adv_pci_dio.c | 33 ++--
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adv_pci_dio.c
b/drivers/staging/comedi/drivers/adv_pci_dio.c
index 69508c8..97fc6b8 100644
--- a/drivers/staging/comedi/drivers/adv_pci_dio.c
+++ b/drivers/staging/comedi/drivers/adv_pci_dio.c
@@ -392,9 +392,6 @@ struct pci_dio_private {
unsigned short IDIFiltrHigh[8]; /* IDI's filter value high signal */
};
-#define devpriv ((struct pci_dio_private *)dev->private)
-#define this_board ((const struct dio_boardtype *)dev->board_ptr)
-
/*
==
*/
@@ -685,6 +682,7 @@ static int pci1760_insn_cnt_write(struct comedi_device *dev,
struct comedi_subdevice *s,
struct comedi_insn *insn, unsigned int *data)
{
+ struct pci_dio_private *devpriv = dev->private;
int ret;
unsigned char chan = CR_CHAN(insn->chanspec) & 0x07;
unsigned char bitmask = 1 << chan;
@@ -727,6 +725,7 @@ static int pci1760_insn_cnt_write(struct comedi_device *dev,
*/
static int pci1760_reset(struct comedi_device *dev)
{
+ struct pci_dio_private *devpriv = dev->private;
int i;
unsigned char omb[4] = { 0x00, 0x00, 0x00, 0x00 };
unsigned char imb[4];
@@ -807,6 +806,8 @@ static int pci1760_reset(struct comedi_device *dev)
*/
static int pci_dio_reset(struct comedi_device *dev)
{
+ const struct dio_boardtype *this_board = comedi_board(dev);
+
switch (this_board->cardtype) {
case TYPE_PCI1730:
outb(0, dev->iobase + PCI1730_DO); /* clear outputs */
@@ -968,6 +969,8 @@ static int pci1760_attach(struct comedi_device *dev,
static int pci_dio_add_di(struct comedi_device *dev, struct comedi_subdevice
*s,
const struct diosubd_data *d, int subdev)
{
+ const struct dio_boardtype *this_board = comedi_board(dev);
+
s->type = COMEDI_SUBD_DI;
s->subdev_flags = SDF_READABLE | SDF_GROUND | SDF_COMMON | d->specflags;
if (d->chans > 16)
@@ -995,6 +998,8 @@ static int pci_dio_add_di(struct comedi_device *dev, struct
comedi_subdevice *s,
static int pci_dio_add_do(struct comedi_device *dev, struct comedi_subdevice
*s,
const struct diosubd_data *d, int subdev)
{
+ const struct dio_boardtype *this_board = comedi_board(dev);
+
s->type = COMEDI_SUBD_DO;
s->subdev_flags = SDF_WRITABLE | SDF_GROUND | SDF_COMMON;
if (d->chans > 16)
@@ -1069,27 +1074,29 @@ static struct pci_dev *pci_dio_find_pci_dev(struct
comedi_device *dev,
static int pci_dio_attach(struct comedi_device *dev,
struct comedi_devconfig *it)
{
+ const struct dio_boardtype *this_board;
+ struct pci_dio_private *devpriv;
struct pci_dev *pcidev;
struct comedi_subdevice *s;
int ret, subdev, n_subdevices, i, j;
- ret = alloc_private(dev, sizeof(struct pci_dio_private));
+ ret = alloc_private(dev, sizeof(*devpriv));
if (ret < 0)
- return -ENOMEM;
+ return ret;
+ devpriv = dev->private;
pcidev = pci_dio_find_pci_dev(dev, it);
if (!pcidev)
return -EIO;
comedi_set_hw_dev(dev, >dev);
+ this_board = comedi_board(dev);
+ dev->board_name = this_board->name;
- if (comedi_pci_enable(pcidev, dev->driver->driver_name)) {
- dev_err(dev->class_dev,
- "Error: Can't enable PCI device and request
regions!\n");
- return -EIO;
- }
+ ret = comedi_pci_enable(pcidev, dev->board_name);
+ if (ret)
+ return ret;
dev->iobase = pci_resource_start(pcidev, this_board->main_pci_region);
- dev->board_name = this_board->name;
if (this_board->cardtype == TYPE_PCI1760) {
n_subdevices = 4; /* 8 IDI, 8 IDO, 2 PWM, 8 CNT */
@@ -1165,12 +1172,14 @@ static int pci_dio_attach(struct comedi_device *dev,
static void pci_dio_detach(struct comedi_device *dev)
{
+ const struct dio_boardtype *this_board = comedi_board(dev);
+ struct pci_dio_private *devpriv = dev->private;
struct pci_dev *pcidev = comedi_to_pci_dev(dev);
int i, j;
struct comedi_subdevice *s;
int subdev;
- if (dev->private) {
+ if (devpriv) {
if (devpriv->valid)
pci_dio_reset(dev);
subdev = 0;
--
1.7.11
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
[PATCH 13/20] staging: comedi: adv_pci_dio: remove function trace messages
Remove the DPRINTK function trace messages and associated
PCI_DIO_EXTDEBUG define. These should not be in the final driver.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/adv_pci_dio.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adv_pci_dio.c
b/drivers/staging/comedi/drivers/adv_pci_dio.c
index 2d4cb7f..69508c8 100644
--- a/drivers/staging/comedi/drivers/adv_pci_dio.c
+++ b/drivers/staging/comedi/drivers/adv_pci_dio.c
@@ -36,15 +36,6 @@ Configuration options:
#include "8255.h"
#include "8253.h"
-#undef PCI_DIO_EXTDEBUG/* if defined, enable extensive debug
logging */
-
-#undef DPRINTK
-#ifdef PCI_DIO_EXTDEBUG
-#define DPRINTK(fmt, args...) printk(fmt, ## args)
-#else
-#define DPRINTK(fmt, args...)
-#endif
-
#define PCI_VENDOR_ID_ADVANTECH0x13fe
/* hardware types of the cards */
@@ -816,8 +807,6 @@ static int pci1760_reset(struct comedi_device *dev)
*/
static int pci_dio_reset(struct comedi_device *dev)
{
- DPRINTK("adv_pci_dio EDBG: BGN: pci171x_reset(...)\n");
-
switch (this_board->cardtype) {
case TYPE_PCI1730:
outb(0, dev->iobase + PCI1730_DO); /* clear outputs */
@@ -917,8 +906,6 @@ static int pci_dio_reset(struct comedi_device *dev)
break;
}
- DPRINTK("adv_pci_dio EDBG: END: pci171x_reset(...)\n");
-
return 0;
}
--
1.7.11
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/20] staging: comedi: adv_pci1723: cleanup card reset
Only one 'reset' of the card is required in the attach. Remove the
one before setting up the subdevices and leave the one before
exiting the attach function.
The 'valid' variable in the private data is not needed. This variable
is used in the detach to determine if it's ok to call the 'reset'
function. Checking if dev->iobase is valid works just as well.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/adv_pci1723.c | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adv_pci1723.c
b/drivers/staging/comedi/drivers/adv_pci1723.c
index 63f0985..cbce06a 100644
--- a/drivers/staging/comedi/drivers/adv_pci1723.c
+++ b/drivers/staging/comedi/drivers/adv_pci1723.c
@@ -107,12 +107,8 @@ TODO:
#define PCI1723_SELECT_CALIBRATION 0x28/* Select the calibration Ref_V
*/
-/* This structure is for data unique to this hardware driver. */
struct pci1723_private {
- int valid; /* card is usable; */
-
unsigned char da_range[8]; /* D/A output range for each channel */
-
short ao_data[8]; /* data output buffer */
};
@@ -262,8 +258,6 @@ static int pci1723_attach_pci(struct comedi_device *dev,
if (ret)
return ret;
- pci1723_reset(dev);
-
s = dev->subdevices + 0;
dev->write_subdev = s;
s->type = COMEDI_SUBD_AO;
@@ -303,8 +297,6 @@ static int pci1723_attach_pci(struct comedi_device *dev,
/* read DIO port state */
s->state = inw(dev->iobase + PCI1723_READ_DIGITAL_INPUT_DATA);
- devpriv->valid = 1;
-
pci1723_reset(dev);
dev_info(dev->class_dev, "%s attached\n", dev->board_name);
@@ -315,15 +307,12 @@ static int pci1723_attach_pci(struct comedi_device *dev,
static void pci1723_detach(struct comedi_device *dev)
{
struct pci_dev *pcidev = comedi_to_pci_dev(dev);
- struct pci1723_private *devpriv = dev->private;
- if (devpriv) {
- if (devpriv->valid)
- pci1723_reset(dev);
- }
if (pcidev) {
- if (dev->iobase)
+ if (dev->iobase) {
+ pci1723_reset(dev);
comedi_pci_disable(pcidev);
+ }
}
}
--
1.7.11
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/20] staging: comedi: adv_pci1723: use attach_pci callback
Convert this PCI driver to use the comedi PCI auto config attach
mechanism by adding an 'attach_pci' callback function. Since the
driver does not require any external configuration options, and
the legacy 'attach' callback is now optional, remove it.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/adv_pci1723.c | 42
1 file changed, 6 insertions(+), 36 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adv_pci1723.c
b/drivers/staging/comedi/drivers/adv_pci1723.c
index 21dfde2..63f0985 100644
--- a/drivers/staging/comedi/drivers/adv_pci1723.c
+++ b/drivers/staging/comedi/drivers/adv_pci1723.c
@@ -238,50 +238,21 @@ static int pci1723_dio_insn_bits(struct comedi_device
*dev,
return insn->n;
}
-static struct pci_dev *pci1723_find_pci_dev(struct comedi_device *dev,
- struct comedi_devconfig *it)
-{
- struct pci_dev *pcidev = NULL;
- int bus = it->options[0];
- int slot = it->options[1];
-
- for_each_pci_dev(pcidev) {
- if (bus || slot) {
- if (bus != pcidev->bus->number ||
- slot != PCI_SLOT(pcidev->devfn))
- continue;
- }
- if (pcidev->vendor != PCI_VENDOR_ID_ADVANTECH)
- continue;
- if (pcidev->device != 0x1723)
- continue;
- return pcidev;
- }
- dev_err(dev->class_dev,
- "No supported board found! (req. bus %d, slot %d)\n",
- bus, slot);
- return NULL;
-}
-
-static int pci1723_attach(struct comedi_device *dev,
- struct comedi_devconfig *it)
+static int pci1723_attach_pci(struct comedi_device *dev,
+ struct pci_dev *pcidev)
{
struct pci1723_private *devpriv;
- struct pci_dev *pcidev;
struct comedi_subdevice *s;
int ret;
+ comedi_set_hw_dev(dev, >dev);
+ dev->board_name = dev->driver->driver_name;
+
ret = alloc_private(dev, sizeof(*devpriv));
if (ret < 0)
return ret;
devpriv = dev->private;
- pcidev = pci1723_find_pci_dev(dev, it);
- if (!pcidev)
- return -EIO;
- comedi_set_hw_dev(dev, >dev);
- dev->board_name = dev->driver->driver_name;
-
ret = comedi_pci_enable(pcidev, dev->board_name);
if (ret)
return ret;
@@ -353,14 +324,13 @@ static void pci1723_detach(struct comedi_device *dev)
if (pcidev) {
if (dev->iobase)
comedi_pci_disable(pcidev);
- pci_dev_put(pcidev);
}
}
static struct comedi_driver adv_pci1723_driver = {
.driver_name= "adv_pci1723",
.module = THIS_MODULE,
- .attach = pci1723_attach,
+ .attach_pci = pci1723_attach_pci,
.detach = pci1723_detach,
};
--
1.7.11
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/20] staging: comedi: adv_pci1723: remove boardinfo
This driver only supports one board type. Remove the boardinfo and
associated code.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/adv_pci1723.c | 139 ---
1 file changed, 42 insertions(+), 97 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adv_pci1723.c
b/drivers/staging/comedi/drivers/adv_pci1723.c
index 68ca075..21dfde2 100644
--- a/drivers/staging/comedi/drivers/adv_pci1723.c
+++ b/drivers/staging/comedi/drivers/adv_pci1723.c
@@ -52,11 +52,6 @@ TODO:
#define PCI_VENDOR_ID_ADVANTECH0x13fe /* Advantech PCI vendor
ID */
-/* hardware types of the cards */
-#define TYPE_PCI1723 0
-
-#define IORANGE_1723 0x2A
-
/* all the registers for the pci1723 board */
#define PCI1723_DA(N) ((N)<<1) /* W: D/A register N (0 to 7) */
@@ -112,37 +107,6 @@ TODO:
#define PCI1723_SELECT_CALIBRATION 0x28/* Select the calibration Ref_V
*/
-/* static unsigned short pci_list_builded=0; =1 list of card is know */
-
-/*
- * Board descriptions for pci1723 boards.
- */
-struct pci1723_board {
- const char *name;
- int vendor_id; /* PCI vendor a device ID of card */
- int device_id;
- int iorange;
- char cardtype;
- int n_aochan; /* num of D/A chans */
- int n_diochan; /* num of DIO chans */
- int ao_maxdata; /* resolution of D/A */
- const struct comedi_lrange *rangelist_ao; /* rangelist for D/A */
-};
-
-static const struct pci1723_board boardtypes[] = {
- {
-.name = "pci1723",
-.vendor_id = PCI_VENDOR_ID_ADVANTECH,
-.device_id = 0x1723,
-.iorange = IORANGE_1723,
-.cardtype = TYPE_PCI1723,
-.n_aochan = 8,
-.n_diochan = 16,
-.ao_maxdata = 0x,
-.rangelist_ao = _bipolar10,
-},
-};
-
/* This structure is for data unique to this hardware driver. */
struct pci1723_private {
int valid; /* card is usable; */
@@ -289,7 +253,8 @@ static struct pci_dev *pci1723_find_pci_dev(struct
comedi_device *dev,
}
if (pcidev->vendor != PCI_VENDOR_ID_ADVANTECH)
continue;
- dev->board_ptr = [0];
+ if (pcidev->device != 0x1723)
+ continue;
return pcidev;
}
dev_err(dev->class_dev,
@@ -301,11 +266,10 @@ static struct pci_dev *pci1723_find_pci_dev(struct
comedi_device *dev,
static int pci1723_attach(struct comedi_device *dev,
struct comedi_devconfig *it)
{
- const struct pci1723_board *this_board;
struct pci1723_private *devpriv;
struct pci_dev *pcidev;
struct comedi_subdevice *s;
- int ret, subdev, n_subdevices;
+ int ret;
ret = alloc_private(dev, sizeof(*devpriv));
if (ret < 0)
@@ -316,76 +280,57 @@ static int pci1723_attach(struct comedi_device *dev,
if (!pcidev)
return -EIO;
comedi_set_hw_dev(dev, >dev);
- this_board = comedi_board(dev);
- dev->board_name = this_board->name;
+ dev->board_name = dev->driver->driver_name;
ret = comedi_pci_enable(pcidev, dev->board_name);
if (ret)
return ret;
dev->iobase = pci_resource_start(pcidev, 2);
- n_subdevices = 0;
-
- if (this_board->n_aochan)
- n_subdevices++;
- if (this_board->n_diochan)
- n_subdevices++;
-
- ret = comedi_alloc_subdevices(dev, n_subdevices);
+ ret = comedi_alloc_subdevices(dev, 2);
if (ret)
return ret;
pci1723_reset(dev);
- subdev = 0;
- if (this_board->n_aochan) {
- s = dev->subdevices + subdev;
- dev->write_subdev = s;
- s->type = COMEDI_SUBD_AO;
- s->subdev_flags = SDF_WRITEABLE | SDF_GROUND | SDF_COMMON;
- s->n_chan = this_board->n_aochan;
- s->maxdata = this_board->ao_maxdata;
- s->len_chanlist = this_board->n_aochan;
- s->range_table = this_board->rangelist_ao;
-
- s->insn_write = pci1723_ao_write_winsn;
- s->insn_read = pci1723_insn_read_ao;
-
- subdev++;
- }
-
- if (this_board->n_diochan) {
- s = dev->subdevices + subdev;
- s->type = COMEDI_SUBD_DIO;
- s->subdev_flags =
- SDF_READABLE | SDF_WRITABLE | SDF_GROUND | SDF_COMMON;
- s->n_chan = this_board->n_diochan;
- s->maxdata = 1;
- s->len_chanlist = this_board->n_diochan;
- s->range_table = _digital;
- s->insn_config = pci1723_dio_insn_config;
- s->insn_bits = pci1723_dio_insn_bits;
-
- /* read DIO config */
- switch (inw(dev->iobase +
[PATCH 09/20] staging: comedi: adv_pci1723: fix initial dio subdevice state and io_bits
The initial state and io_bits for the dio subdevice is determined in
the pci1723_attach() but it's being saved in the wrong subdevice. Move
the code so it gets saved correctly.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/adv_pci1723.c | 29 ++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adv_pci1723.c
b/drivers/staging/comedi/drivers/adv_pci1723.c
index a790bb7..68ca075 100644
--- a/drivers/staging/comedi/drivers/adv_pci1723.c
+++ b/drivers/staging/comedi/drivers/adv_pci1723.c
@@ -350,6 +350,21 @@ static int pci1723_attach(struct comedi_device *dev,
s->insn_write = pci1723_ao_write_winsn;
s->insn_read = pci1723_insn_read_ao;
+ subdev++;
+ }
+
+ if (this_board->n_diochan) {
+ s = dev->subdevices + subdev;
+ s->type = COMEDI_SUBD_DIO;
+ s->subdev_flags =
+ SDF_READABLE | SDF_WRITABLE | SDF_GROUND | SDF_COMMON;
+ s->n_chan = this_board->n_diochan;
+ s->maxdata = 1;
+ s->len_chanlist = this_board->n_diochan;
+ s->range_table = _digital;
+ s->insn_config = pci1723_dio_insn_config;
+ s->insn_bits = pci1723_dio_insn_bits;
+
/* read DIO config */
switch (inw(dev->iobase + PCI1723_DIGITAL_IO_PORT_MODE)
& 0x03) {
@@ -372,20 +387,6 @@ static int pci1723_attach(struct comedi_device *dev,
subdev++;
}
- if (this_board->n_diochan) {
- s = dev->subdevices + subdev;
- s->type = COMEDI_SUBD_DIO;
- s->subdev_flags =
- SDF_READABLE | SDF_WRITABLE | SDF_GROUND | SDF_COMMON;
- s->n_chan = this_board->n_diochan;
- s->maxdata = 1;
- s->len_chanlist = this_board->n_diochan;
- s->range_table = _digital;
- s->insn_config = pci1723_dio_insn_config;
- s->insn_bits = pci1723_dio_insn_bits;
- subdev++;
- }
-
devpriv->valid = 1;
pci1723_reset(dev);
--
1.7.11
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/20] staging: comedi: adv_pci1723: remove range_pci1723
This comedi_lrange is the same as the global range_bipolar10
exported by the comedi core. Use that range instead.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/adv_pci1723.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adv_pci1723.c
b/drivers/staging/comedi/drivers/adv_pci1723.c
index cc67dccb..a790bb7 100644
--- a/drivers/staging/comedi/drivers/adv_pci1723.c
+++ b/drivers/staging/comedi/drivers/adv_pci1723.c
@@ -114,11 +114,6 @@ TODO:
/* static unsigned short pci_list_builded=0; =1 list of card is know */
-static const struct comedi_lrange range_pci1723 = { 1, {
- BIP_RANGE(10)
- }
-};
-
/*
* Board descriptions for pci1723 boards.
*/
@@ -144,7 +139,7 @@ static const struct pci1723_board boardtypes[] = {
.n_aochan = 8,
.n_diochan = 16,
.ao_maxdata = 0x,
-.rangelist_ao = _pci1723,
+.rangelist_ao = _bipolar10,
},
};
--
1.7.11
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/20] staging: comedi: adv_pci1723: remove devpriv and this_board macros
The devpriv macro relies on a local variable having a specific name.
Remove it.
The this_board macro in this driver is a bit different in this driver.
In other comedi drivers, this macro returns the dev->board_ptr. In this
driver its simply 'boardtypes' which returns the first boardinfo element.
Remove this macro also by making sure the dev->board_ptr is set in the
pci1723_find_pci_dev() function and using the comedi_board() helper
to get the pointer in pci1723_attach().
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/adv_pci1723.c | 35 ++--
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adv_pci1723.c
b/drivers/staging/comedi/drivers/adv_pci1723.c
index 3c4978a..cc67dccb 100644
--- a/drivers/staging/comedi/drivers/adv_pci1723.c
+++ b/drivers/staging/comedi/drivers/adv_pci1723.c
@@ -157,16 +157,12 @@ struct pci1723_private {
short ao_data[8]; /* data output buffer */
};
-/* The following macro to make it easy to access the private structure. */
-#define devpriv ((struct pci1723_private *)dev->private)
-
-#define this_board boardtypes
-
/*
* The pci1723 card reset;
*/
static int pci1723_reset(struct comedi_device *dev)
{
+ struct pci1723_private *devpriv = dev->private;
int i;
outw(0x01, dev->iobase + PCI1723_SYN_SET);
@@ -196,6 +192,7 @@ static int pci1723_insn_read_ao(struct comedi_device *dev,
struct comedi_subdevice *s,
struct comedi_insn *insn, unsigned int *data)
{
+ struct pci1723_private *devpriv = dev->private;
int n, chan;
chan = CR_CHAN(insn->chanspec);
@@ -212,6 +209,7 @@ static int pci1723_ao_write_winsn(struct comedi_device *dev,
struct comedi_subdevice *s,
struct comedi_insn *insn, unsigned int *data)
{
+ struct pci1723_private *devpriv = dev->private;
int n, chan;
chan = CR_CHAN(insn->chanspec);
@@ -296,6 +294,7 @@ static struct pci_dev *pci1723_find_pci_dev(struct
comedi_device *dev,
}
if (pcidev->vendor != PCI_VENDOR_ID_ADVANTECH)
continue;
+ dev->board_ptr = [0];
return pcidev;
}
dev_err(dev->class_dev,
@@ -307,32 +306,29 @@ static struct pci_dev *pci1723_find_pci_dev(struct
comedi_device *dev,
static int pci1723_attach(struct comedi_device *dev,
struct comedi_devconfig *it)
{
+ const struct pci1723_board *this_board;
+ struct pci1723_private *devpriv;
struct pci_dev *pcidev;
struct comedi_subdevice *s;
int ret, subdev, n_subdevices;
- printk(KERN_ERR "comedi%d: adv_pci1723: board=%s",
- dev->minor, this_board->name);
-
- ret = alloc_private(dev, sizeof(struct pci1723_private));
- if (ret < 0) {
- printk(" - Allocation failed!\n");
- return -ENOMEM;
- }
+ ret = alloc_private(dev, sizeof(*devpriv));
+ if (ret < 0)
+ return ret;
+ devpriv = dev->private;
pcidev = pci1723_find_pci_dev(dev, it);
if (!pcidev)
return -EIO;
comedi_set_hw_dev(dev, >dev);
+ this_board = comedi_board(dev);
+ dev->board_name = this_board->name;
- ret = comedi_pci_enable(pcidev, "adv_pci1723");
+ ret = comedi_pci_enable(pcidev, dev->board_name);
if (ret)
return ret;
-
dev->iobase = pci_resource_start(pcidev, 2);
- dev->board_name = this_board->name;
-
n_subdevices = 0;
if (this_board->n_aochan)
@@ -399,14 +395,17 @@ static int pci1723_attach(struct comedi_device *dev,
pci1723_reset(dev);
+ dev_info(dev->class_dev, "%s attached\n", dev->board_name);
+
return 0;
}
static void pci1723_detach(struct comedi_device *dev)
{
struct pci_dev *pcidev = comedi_to_pci_dev(dev);
+ struct pci1723_private *devpriv = dev->private;
- if (dev->private) {
+ if (devpriv) {
if (devpriv->valid)
pci1723_reset(dev);
}
--
1.7.11
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/20] staging: comedi: adv_pci1723: remove function trace messages
Remove the DPRINTK function trace messages. These should not be
in the final driver.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/adv_pci1723.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adv_pci1723.c
b/drivers/staging/comedi/drivers/adv_pci1723.c
index dfde0f6..3c4978a 100644
--- a/drivers/staging/comedi/drivers/adv_pci1723.c
+++ b/drivers/staging/comedi/drivers/adv_pci1723.c
@@ -168,7 +168,6 @@ struct pci1723_private {
static int pci1723_reset(struct comedi_device *dev)
{
int i;
- DPRINTK("adv_pci1723 EDBG: BGN: pci1723_reset(...)\n");
outw(0x01, dev->iobase + PCI1723_SYN_SET);
/* set synchronous output mode */
@@ -190,7 +189,6 @@ static int pci1723_reset(struct comedi_device *dev)
/* set asynchronous output mode */
outw(0, dev->iobase + PCI1723_SYN_SET);
- DPRINTK("adv_pci1723 EDBG: END: pci1723_reset(...)\n");
return 0;
}
@@ -201,7 +199,6 @@ static int pci1723_insn_read_ao(struct comedi_device *dev,
int n, chan;
chan = CR_CHAN(insn->chanspec);
- DPRINTK(" adv_PCI1723 DEBUG: pci1723_insn_read_ao() -\n");
for (n = 0; n < insn->n; n++)
data[n] = devpriv->ao_data[chan];
@@ -218,8 +215,6 @@ static int pci1723_ao_write_winsn(struct comedi_device *dev,
int n, chan;
chan = CR_CHAN(insn->chanspec);
- DPRINTK("PCI1723: the pci1723_ao_write_winsn() --\n");
-
for (n = 0; n < insn->n; n++) {
devpriv->ao_data[chan] = data[n];
--
1.7.11
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 2/2] mm: Batch page_check_references in shrink_page_list sharing the same i_mmap_mutex
In shrink_page_list, call to page_referenced_file will causes the
acquisition/release of mapping->i_mmap_mutex for each page in the page
list. However, it is very likely that successive pages in the list
share the same mapping and we can reduce the frequency of i_mmap_mutex
acquisition by holding the mutex in shrink_page_list. This improves the
performance when the system has a lot page reclamations for file mapped
pages if workloads are using a lot of memory for page cache.
Tim
---
Signed-off-by: Tim Chen
---
diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 4b974ae..f0174ae 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -156,8 +156,8 @@ static inline void page_dup_rmap(struct page *page)
/*
* Called from mm/vmscan.c to handle paging out
*/
-int page_referenced(struct page *, int is_locked,
- struct mem_cgroup *memcg, unsigned long *vm_flags);
+int page_referenced(struct page *, int is_locked, struct mem_cgroup *memcg,
+ unsigned long *vm_flags, int mmap_mutex_locked);
int page_referenced_one(struct page *, struct vm_area_struct *,
unsigned long address, unsigned int *mapcount, unsigned long *vm_flags);
@@ -175,7 +175,7 @@ enum ttu_flags {
bool is_vma_temporary_stack(struct vm_area_struct *vma);
-int try_to_unmap(struct page *, enum ttu_flags flags, int file_mapped);
+int try_to_unmap(struct page *, enum ttu_flags flags, int mmap_mutex_locked);
int try_to_unmap_one(struct page *, struct vm_area_struct *,
unsigned long address, enum ttu_flags flags);
diff --git a/mm/migrate.c b/mm/migrate.c
index 102a5b1..1aa37b1 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -918,7 +918,8 @@ static int unmap_and_move_huge_page(new_page_t get_new_page,
if (PageAnon(hpage))
anon_vma = page_get_anon_vma(hpage);
- try_to_unmap(hpage, TTU_MIGRATION|TTU_IGNORE_MLOCK|TTU_IGNORE_ACCESS,
0);
+ try_to_unmap(hpage,
+TTU_MIGRATION|TTU_IGNORE_MLOCK|TTU_IGNORE_ACCESS, 0);
if (!page_mapped(hpage))
rc = move_to_new_page(new_hpage, hpage, 1, mode);
diff --git a/mm/rmap.c b/mm/rmap.c
index cb7de48..63fc84b 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -820,7 +820,7 @@ static int page_referenced_anon(struct page *page,
*/
static int page_referenced_file(struct page *page,
struct mem_cgroup *memcg,
- unsigned long *vm_flags)
+ unsigned long *vm_flags, int mmap_mutex_locked)
{
unsigned int mapcount;
struct address_space *mapping = page->mapping;
@@ -839,11 +839,14 @@ static int page_referenced_file(struct page *page,
/*
* The page lock not only makes sure that page->mapping cannot
* suddenly be NULLified by truncation, it makes sure that the
-* structure at mapping cannot be freed and reused yet.
-* We should have taken mapping->i_mmap_mutex.
+* structure at mapping cannot be freed and reused yet,
+* so we can safely take mapping->i_mmap_mutex.
*/
BUG_ON(!PageLocked(page));
+ if (!mmap_mutex_locked)
+ mutex_lock(>i_mmap_mutex);
+
/*
* i_mmap_mutex does not stabilize mapcount at all, but mapcount
* is more likely to be accurate if we note it after spinning.
@@ -867,6 +870,8 @@ static int page_referenced_file(struct page *page,
break;
}
+ if (!mmap_mutex_locked)
+ mutex_unlock(>i_mmap_mutex);
return referenced;
}
@@ -883,7 +888,7 @@ static int page_referenced_file(struct page *page,
int page_referenced(struct page *page,
int is_locked,
struct mem_cgroup *memcg,
- unsigned long *vm_flags)
+ unsigned long *vm_flags, int mmap_mutex_locked)
{
int referenced = 0;
int we_locked = 0;
@@ -903,14 +908,9 @@ int page_referenced(struct page *page,
else if (PageAnon(page))
referenced += page_referenced_anon(page, memcg,
vm_flags);
- else if (page->mapping) {
- if (!is_locked)
- mutex_lock(>mapping->i_mmap_mutex);
+ else if (page->mapping)
referenced += page_referenced_file(page, memcg,
- vm_flags);
- if (!is_locked)
- mutex_unlock(>mapping->i_mmap_mutex);
- }
+vm_flags, mmap_mutex_locked);
if (we_locked)
unlock_page(page);
@@ -1550,7 +1550,8 @@ static int try_to_unmap_anon(struct page *page, enum
ttu_flags flags)
* vm_flags for that VMA.
[RFC PATCH 1/2] mm: Batch unmapping of file mapped pages in shrink_page_list
We gather the pages that need to be unmapped in shrink_page_list. We do
the unmap in a single batch to reduce the frequency of acquisition of
the tree lock protecting the address mapping radix tree. This is
possible as successive pages likely share the same mapping in the
__remove_mapping_batch routine. This avoids excessive cache bouncing of
the tree lock when page reclamations are occurring simultaneously.
Tim
---
Signed-off-by: Tim Chen
---
diff --git a/mm/vmscan.c b/mm/vmscan.c
index aac5672..a538565 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -600,6 +600,85 @@ cannot_free:
return 0;
}
+/* Same as __remove_mapping, but batching operations to minimize locking */
+/* Pages to be unmapped should be locked first */
+static int __remove_mapping_batch(struct list_head *unmap_pages,
+ struct list_head *ret_pages,
+ struct list_head *free_pages)
+{
+ struct address_space *mapping, *next;
+ LIST_HEAD(swap_pages);
+ swp_entry_t swap;
+ struct page *page;
+ int nr_reclaimed;
+
+ mapping = NULL;
+ nr_reclaimed = 0;
+ while (!list_empty(unmap_pages)) {
+
+ page = lru_to_page(unmap_pages);
+ BUG_ON(!PageLocked(page));
+
+ list_del(>lru);
+ next = page_mapping(page);
+ if (mapping != next) {
+ if (mapping)
+ spin_unlock_irq(>tree_lock);
+ mapping = next;
+ spin_lock_irq(>tree_lock);
+ }
+
+ if (!page_freeze_refs(page, 2))
+ goto cannot_free;
+ if (unlikely(PageDirty(page))) {
+ page_unfreeze_refs(page, 2);
+ goto cannot_free;
+ }
+
+ if (PageSwapCache(page)) {
+ __delete_from_swap_cache(page);
+ /* swapcahce_free need to be called without tree_lock */
+ list_add(>lru, _pages);
+ } else {
+ void (*freepage)(struct page *);
+
+ freepage = mapping->a_ops->freepage;
+
+ __delete_from_page_cache(page);
+ mem_cgroup_uncharge_cache_page(page);
+
+ if (freepage != NULL)
+ freepage(page);
+
+ unlock_page(page);
+ nr_reclaimed++;
+ list_add(>lru, free_pages);
+ }
+ continue;
+cannot_free:
+ unlock_page(page);
+ list_add(>lru, ret_pages);
+ VM_BUG_ON(PageLRU(page) || PageUnevictable(page));
+
+ }
+
+ if (mapping)
+ spin_unlock_irq(>tree_lock);
+
+ while (!list_empty(_pages)) {
+ page = lru_to_page(_pages);
+ list_del(>lru);
+
+ swap.val = page_private(page);
+ swapcache_free(swap, page);
+
+ unlock_page(page);
+ nr_reclaimed++;
+ list_add(>lru, free_pages);
+ }
+
+ return nr_reclaimed;
+}
/*
* Attempt to detach a locked page from its ->mapping. If it is dirty or if
* someone else has a ref on the page, abort and return 0. If it was
@@ -771,6 +850,7 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
{
LIST_HEAD(ret_pages);
LIST_HEAD(free_pages);
+ LIST_HEAD(unmap_pages);
int pgactivate = 0;
unsigned long nr_dirty = 0;
unsigned long nr_congested = 0;
@@ -969,17 +1049,13 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
}
}
- if (!mapping || !__remove_mapping(mapping, page))
+ if (!mapping)
goto keep_locked;
- /*
-* At this point, we have no other references and there is
-* no way to pick any more up (removed from LRU, removed
-* from pagecache). Can use non-atomic bitops now (and
-* we obviously don't have to worry about waking up a process
-* waiting on the page lock, because there are no references.
-*/
- __clear_page_locked(page);
+ /* remove pages from mapping in batch at end of loop */
+ list_add(>lru, _pages);
+ continue;
+
free_it:
nr_reclaimed++;
@@ -1014,6 +1090,9 @@ keep_lumpy:
VM_BUG_ON(PageLRU(page) || PageUnevictable(page));
}
+ nr_reclaimed += __remove_mapping_batch(_pages, _pages,
+ _pages);
+
/*
* Tag a zone as congested if all the dirty pages encountered were
* backed by a congested BDI. In this case, reclaimers should just
--
[PATCH 05/20] staging: comedi: adv_pci1710: remove forward declarations
Move some of the functions to remove the need for the forward
declarations.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/adv_pci1710.c | 297 +--
1 file changed, 140 insertions(+), 157 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adv_pci1710.c
b/drivers/staging/comedi/drivers/adv_pci1710.c
index 5bea385..66bd3858 100644
--- a/drivers/staging/comedi/drivers/adv_pci1710.c
+++ b/drivers/staging/comedi/drivers/adv_pci1710.c
@@ -330,30 +330,108 @@ struct pci1710_private {
* internal state */
};
+/* used for gain list programming */
+static const unsigned int muxonechan[] = {
+ 0x, 0x0101, 0x0202, 0x0303, 0x0404, 0x0505, 0x0606, 0x0707,
+ 0x0808, 0x0909, 0x0a0a, 0x0b0b, 0x0c0c, 0x0d0d, 0x0e0e, 0x0f0f,
+ 0x1010, 0x, 0x1212, 0x1313, 0x1414, 0x1515, 0x1616, 0x1717,
+ 0x1818, 0x1919, 0x1a1a, 0x1b1b, 0x1c1c, 0x1d1d, 0x1e1e, 0x1f1f
+};
+
/*
==
+ Check if channel list from user is builded correctly
+ If it's ok, then program scan/gain logic.
+ This works for all cards.
*/
-
static int check_channel_list(struct comedi_device *dev,
struct comedi_subdevice *s,
- unsigned int *chanlist, unsigned int n_chan);
+ unsigned int *chanlist, unsigned int n_chan)
+{
+ unsigned int chansegment[32];
+ unsigned int i, nowmustbechan, seglen, segpos;
+
+ /* correct channel and range number check itself comedi/range.c */
+ if (n_chan < 1) {
+ comedi_error(dev, "range/channel list is empty!");
+ return 0;
+ }
+
+ if (n_chan == 1)
+ return 1; /* seglen=1 */
+
+ chansegment[0] = chanlist[0]; /* first channel is every time ok */
+ for (i = 1, seglen = 1; i < n_chan; i++, seglen++) {
+ if (chanlist[0] == chanlist[i])
+ break; /* we detected a loop, stop */
+ if ((CR_CHAN(chanlist[i]) & 1) &&
+ (CR_AREF(chanlist[i]) == AREF_DIFF)) {
+ comedi_error(dev, "Odd channel cannot be differential
input!\n");
+ return 0;
+ }
+ nowmustbechan = (CR_CHAN(chansegment[i - 1]) + 1) % s->n_chan;
+ if (CR_AREF(chansegment[i - 1]) == AREF_DIFF)
+ nowmustbechan = (nowmustbechan + 1) % s->n_chan;
+ if (nowmustbechan != CR_CHAN(chanlist[i])) {
+ printk("channel list must be continuous!
chanlist[%i]=%d but must be %d or %d!\n",
+ i, CR_CHAN(chanlist[i]), nowmustbechan,
+ CR_CHAN(chanlist[0]));
+ return 0;
+ }
+ chansegment[i] = chanlist[i]; /* next correct channel in list */
+ }
+
+ for (i = 0, segpos = 0; i < n_chan; i++) {
+ if (chanlist[i] != chansegment[i % seglen]) {
+ printk("bad channel, reference or range number!
chanlist[%i]=%d,%d,%d and not %d,%d,%d!\n",
+ i, CR_CHAN(chansegment[i]),
+ CR_RANGE(chansegment[i]),
+ CR_AREF(chansegment[i]),
+ CR_CHAN(chanlist[i % seglen]),
+ CR_RANGE(chanlist[i % seglen]),
+ CR_AREF(chansegment[i % seglen]));
+ return 0;
+ }
+ }
+ return seglen;
+}
+
static void setup_channel_list(struct comedi_device *dev,
struct comedi_subdevice *s,
unsigned int *chanlist, unsigned int n_chan,
- unsigned int seglen);
-static void start_pacer(struct comedi_device *dev, int mode,
- unsigned int divisor1, unsigned int divisor2);
-static int pci1710_reset(struct comedi_device *dev);
-static int pci171x_ai_cancel(struct comedi_device *dev,
-struct comedi_subdevice *s);
+ unsigned int seglen)
+{
+ const struct boardtype *this_board = comedi_board(dev);
+ struct pci1710_private *devpriv = dev->private;
+ unsigned int i, range, chanprog;
-/* used for gain list programming */
-static const unsigned int muxonechan[] = {
- 0x, 0x0101, 0x0202, 0x0303, 0x0404, 0x0505, 0x0606, 0x0707,
- 0x0808, 0x0909, 0x0a0a, 0x0b0b, 0x0c0c, 0x0d0d, 0x0e0e, 0x0f0f,
- 0x1010, 0x, 0x1212, 0x1313, 0x1414, 0x1515, 0x1616, 0x1717,
- 0x1818, 0x1919, 0x1a1a, 0x1b1b, 0x1c1c, 0x1d1d, 0x1e1e, 0x1f1f
-};
+ devpriv->act_chanlist_len = seglen;
+ devpriv->act_chanlist_pos = 0;
+
+ for (i = 0; i < seglen; i++) { /* store range list
[RFC PATCH 0/2] mm: Batch page reclamation under shink_page_list
To do page reclamation in shrink_page_list function, there are two locks taken on a page by page basis. One is the tree lock protecting the radix tree of the page mapping and the other is the mapping->i_mmap_mutex protecting the reverse mapping of file maped pages. I tried to batch the operations on pages sharing the same lock to reduce lock contentions. The first patch batch the operations under tree lock while the second one batch the checking of file page references under the i_mmap_mutex. I managed to get 14% throughput improvement when with a workload putting heavy pressure of page cache by reading many large mmaped files simultaneously on a 8 socket Westmere server. There are some ugly hacks in the patches to pass information about whether the i_mmap_mutex is locked. Any suggestions on a better approach and reviews of the patches are appreciated. Tim Signed-off-by: Tim Chen --- Diffstat include/linux/rmap.h |6 +- mm/memory-failure.c |2 +- mm/migrate.c |4 +- mm/rmap.c| 28 ++ mm/vmscan.c | 139 +- 5 files changed, 147 insertions(+), 32 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/20] staging: comedi: adv_pci1710: remove '0' and 'NULL' boardinfo data
Remove all the boardinfo data that is set to '0' or 'NULL'.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/adv_pci1710.c | 23 ---
1 file changed, 23 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adv_pci1710.c
b/drivers/staging/comedi/drivers/adv_pci1710.c
index 58de025..5bea385 100644
--- a/drivers/staging/comedi/drivers/adv_pci1710.c
+++ b/drivers/staging/comedi/drivers/adv_pci1710.c
@@ -247,7 +247,6 @@ static const struct boardtype boardtypes[] = {
.have_irq = 1,
.cardtype = TYPE_PCI171X,
.n_aichan = 16,
- .n_aichand = 0,
.n_aochan = 2,
.n_dichan = 16,
.n_dochan = 16,
@@ -267,36 +266,19 @@ static const struct boardtype boardtypes[] = {
.cardtype = TYPE_PCI1713,
.n_aichan = 32,
.n_aichand = 16,
- .n_aochan = 0,
- .n_dichan = 0,
- .n_dochan = 0,
- .n_counter = 0,
.ai_maxdata = 0x0fff,
- .ao_maxdata = 0x,
.rangelist_ai = _pci1710_3,
.rangecode_ai = range_codes_pci1710_3,
- .rangelist_ao = NULL,
.ai_ns_min = 1,
.fifo_half_size = 2048,
}, {
.name = "pci1720",
.device_id = 0x1720,
.iorange= IORANGE_1720,
- .have_irq = 0,
.cardtype = TYPE_PCI1720,
- .n_aichan = 0,
- .n_aichand = 0,
.n_aochan = 4,
- .n_dichan = 0,
- .n_dochan = 0,
- .n_counter = 0,
- .ai_maxdata = 0x,
.ao_maxdata = 0x0fff,
- .rangelist_ai = NULL,
- .rangecode_ai = NULL,
.rangelist_ao = _pci1720,
- .ai_ns_min = 0,
- .fifo_half_size = 0,
}, {
.name = "pci1731",
.device_id = 0x1731,
@@ -304,16 +286,11 @@ static const struct boardtype boardtypes[] = {
.have_irq = 1,
.cardtype = TYPE_PCI171X,
.n_aichan = 16,
- .n_aichand = 0,
- .n_aochan = 0,
.n_dichan = 16,
.n_dochan = 16,
- .n_counter = 0,
.ai_maxdata = 0x0fff,
- .ao_maxdata = 0x,
.rangelist_ai = _pci17x1,
.rangecode_ai = range_codes_pci17x1,
- .rangelist_ao = NULL,
.ai_ns_min = 1,
.fifo_half_size = 512,
}, {
--
1.7.11
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/20] staging: comedi: adv_pci1710: convert boardinfo initialization to C99 format
Convert the boardinfo initialization to C99 format to make it
less error prone.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/adv_pci1710.c | 152 +--
1 file changed, 118 insertions(+), 34 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adv_pci1710.c
b/drivers/staging/comedi/drivers/adv_pci1710.c
index 7f27c59..58de025 100644
--- a/drivers/staging/comedi/drivers/adv_pci1710.c
+++ b/drivers/staging/comedi/drivers/adv_pci1710.c
@@ -202,40 +202,124 @@ struct boardtype {
};
static const struct boardtype boardtypes[] = {
- {"pci1710", 0x1710,
-IORANGE_171x, 1, TYPE_PCI171X,
-16, 8, 2, 16, 16, 1, 0x0fff, 0x0fff,
-_pci1710_3, range_codes_pci1710_3,
-_pci171x_da,
-1, 2048},
- {"pci1710hg", 0x1710,
-IORANGE_171x, 1, TYPE_PCI171X,
-16, 8, 2, 16, 16, 1, 0x0fff, 0x0fff,
-_pci1710hg, range_codes_pci1710hg,
-_pci171x_da,
-1, 2048},
- {"pci1711", 0x1711,
-IORANGE_171x, 1, TYPE_PCI171X,
-16, 0, 2, 16, 16, 1, 0x0fff, 0x0fff,
-_pci17x1, range_codes_pci17x1, _pci171x_da,
-1, 512},
- {"pci1713", 0x1713,
-IORANGE_171x, 1, TYPE_PCI1713,
-32, 16, 0, 0, 0, 0, 0x0fff, 0x,
-_pci1710_3, range_codes_pci1710_3, NULL,
-1, 2048},
- {"pci1720", 0x1720,
-IORANGE_1720, 0, TYPE_PCI1720,
-0, 0, 4, 0, 0, 0, 0x, 0x0fff,
-NULL, NULL, _pci1720,
-0, 0},
- {"pci1731", 0x1731,
-IORANGE_171x, 1, TYPE_PCI171X,
-16, 0, 0, 16, 16, 0, 0x0fff, 0x,
-_pci17x1, range_codes_pci17x1, NULL,
-1, 512},
- /* dummy entry corresponding to driver name */
- {.name = DRV_NAME},
+ {
+ .name = "pci1710",
+ .device_id = 0x1710,
+ .iorange= IORANGE_171x,
+ .have_irq = 1,
+ .cardtype = TYPE_PCI171X,
+ .n_aichan = 16,
+ .n_aichand = 8,
+ .n_aochan = 2,
+ .n_dichan = 16,
+ .n_dochan = 16,
+ .n_counter = 1,
+ .ai_maxdata = 0x0fff,
+ .ao_maxdata = 0x0fff,
+ .rangelist_ai = _pci1710_3,
+ .rangecode_ai = range_codes_pci1710_3,
+ .rangelist_ao = _pci171x_da,
+ .ai_ns_min = 1,
+ .fifo_half_size = 2048,
+ }, {
+ .name = "pci1710hg",
+ .device_id = 0x1710,
+ .iorange= IORANGE_171x,
+ .have_irq = 1,
+ .cardtype = TYPE_PCI171X,
+ .n_aichan = 16,
+ .n_aichand = 8,
+ .n_aochan = 2,
+ .n_dichan = 16,
+ .n_dochan = 16,
+ .n_counter = 1,
+ .ai_maxdata = 0x0fff,
+ .ao_maxdata = 0x0fff,
+ .rangelist_ai = _pci1710hg,
+ .rangecode_ai = range_codes_pci1710hg,
+ .rangelist_ao = _pci171x_da,
+ .ai_ns_min = 1,
+ .fifo_half_size = 2048,
+ }, {
+ .name = "pci1711",
+ .device_id = 0x1711,
+ .iorange= IORANGE_171x,
+ .have_irq = 1,
+ .cardtype = TYPE_PCI171X,
+ .n_aichan = 16,
+ .n_aichand = 0,
+ .n_aochan = 2,
+ .n_dichan = 16,
+ .n_dochan = 16,
+ .n_counter = 1,
+ .ai_maxdata = 0x0fff,
+ .ao_maxdata = 0x0fff,
+ .rangelist_ai = _pci17x1,
+ .rangecode_ai = range_codes_pci17x1,
+ .rangelist_ao = _pci171x_da,
+ .ai_ns_min = 1,
+ .fifo_half_size = 512,
+ }, {
+ .name = "pci1713",
+ .device_id = 0x1713,
+ .iorange= IORANGE_171x,
+ .have_irq = 1,
+ .cardtype = TYPE_PCI1713,
+ .n_aichan = 32,
+ .n_aichand = 16,
+ .n_aochan = 0,
+ .n_dichan = 0,
+ .n_dochan = 0,
+ .n_counter = 0,
+ .ai_maxdata = 0x0fff,
+ .ao_maxdata = 0x,
+ .rangelist_ai = _pci1710_3,
+ .rangecode_ai = range_codes_pci1710_3,
+ .rangelist_ao = NULL,
+ .ai_ns_min = 1,
+ .fifo_half_size = 2048,
+ }, {
+ .name = "pci1720",
+ .device_id
[PATCH 02/20] staging: comedi: adv_pci1710: remove devpriv and this_board macros
These macros rely on a local variable having a specific name. Remove
them and use the comedi_board() helper to get the this_board pointer.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/adv_pci1710.c | 44
1 file changed, 39 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adv_pci1710.c
b/drivers/staging/comedi/drivers/adv_pci1710.c
index 7c4f0de..7f27c59 100644
--- a/drivers/staging/comedi/drivers/adv_pci1710.c
+++ b/drivers/staging/comedi/drivers/adv_pci1710.c
@@ -269,9 +269,6 @@ struct pci1710_private {
* internal state */
};
-#define devpriv ((struct pci1710_private *)dev->private)
-#define this_board ((const struct boardtype *)dev->board_ptr)
-
/*
==
*/
@@ -304,8 +301,10 @@ static int pci171x_insn_read_ai(struct comedi_device *dev,
struct comedi_subdevice *s,
struct comedi_insn *insn, unsigned int *data)
{
+ struct pci1710_private *devpriv = dev->private;
int n, timeout;
#ifdef PCI171x_PARANOIDCHECK
+ const struct boardtype *this_board = comedi_board(dev);
unsigned int idata;
#endif
@@ -359,6 +358,7 @@ static int pci171x_insn_write_ao(struct comedi_device *dev,
struct comedi_subdevice *s,
struct comedi_insn *insn, unsigned int *data)
{
+ struct pci1710_private *devpriv = dev->private;
int n, chan, range, ofs;
chan = CR_CHAN(insn->chanspec);
@@ -391,6 +391,7 @@ static int pci171x_insn_read_ao(struct comedi_device *dev,
struct comedi_subdevice *s,
struct comedi_insn *insn, unsigned int *data)
{
+ struct pci1710_private *devpriv = dev->private;
int n, chan;
chan = CR_CHAN(insn->chanspec);
@@ -461,6 +462,7 @@ static int pci171x_insn_counter_write(struct comedi_device
*dev,
struct comedi_insn *insn,
unsigned int *data)
{
+ struct pci1710_private *devpriv = dev->private;
uint msb, lsb, ccntrl, status;
lsb = data[0] & 0x00FF;
@@ -492,6 +494,7 @@ static int pci171x_insn_counter_config(struct comedi_device
*dev,
{
#ifdef unused
/* This doesn't work like a normal Comedi counter config */
+ struct pci1710_private *devpriv = dev->private;
uint ccntrl = 0;
devpriv->cnt0_write_wait = data[0] & 0x20;
@@ -527,6 +530,7 @@ static int pci1720_insn_write_ao(struct comedi_device *dev,
struct comedi_subdevice *s,
struct comedi_insn *insn, unsigned int *data)
{
+ struct pci1710_private *devpriv = dev->private;
int n, rangereg, chan;
chan = CR_CHAN(insn->chanspec);
@@ -553,9 +557,11 @@ static int pci1720_insn_write_ao(struct comedi_device *dev,
static void interrupt_pci1710_every_sample(void *d)
{
struct comedi_device *dev = d;
+ struct pci1710_private *devpriv = dev->private;
struct comedi_subdevice *s = dev->subdevices + 0;
int m;
#ifdef PCI171x_PARANOIDCHECK
+ const struct boardtype *this_board = comedi_board(dev);
short sampl;
#endif
@@ -633,8 +639,10 @@ static void interrupt_pci1710_every_sample(void *d)
static int move_block_from_fifo(struct comedi_device *dev,
struct comedi_subdevice *s, int n, int turn)
{
+ struct pci1710_private *devpriv = dev->private;
int i, j;
#ifdef PCI171x_PARANOIDCHECK
+ const struct boardtype *this_board = comedi_board(dev);
int sampl;
#endif
@@ -677,6 +685,8 @@ static int move_block_from_fifo(struct comedi_device *dev,
static void interrupt_pci1710_half_fifo(void *d)
{
struct comedi_device *dev = d;
+ const struct boardtype *this_board = comedi_board(dev);
+ struct pci1710_private *devpriv = dev->private;
struct comedi_subdevice *s = dev->subdevices + 0;
int m, samplesinbuf;
@@ -731,6 +741,7 @@ static void interrupt_pci1710_half_fifo(void *d)
static irqreturn_t interrupt_service_pci1710(int irq, void *d)
{
struct comedi_device *dev = d;
+ struct pci1710_private *devpriv = dev->private;
if (!dev->attached) /* is device attached? */
return IRQ_NONE;/* no, exit */
@@ -766,6 +777,8 @@ static irqreturn_t interrupt_service_pci1710(int irq, void
*d)
static int pci171x_ai_docmd_and_mode(int mode, struct comedi_device *dev,
struct comedi_subdevice *s)
{
+ const struct boardtype *this_board = comedi_board(dev);
+ struct pci1710_private *devpriv = dev->private;
unsigned int divisor1 = 0, divisor2 = 0;
[PATCH 01/20] staging: comedi: adv_pci1710: remove function trace messages
The macros PCI171X_EXTDEBUG and DPRINTK enable a number of function
trace messages. These trace messages should not be in the final
driver. Remove them.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/adv_pci1710.c | 132 +--
1 file changed, 5 insertions(+), 127 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adv_pci1710.c
b/drivers/staging/comedi/drivers/adv_pci1710.c
index 6b4d0d6..7c4f0de 100644
--- a/drivers/staging/comedi/drivers/adv_pci1710.c
+++ b/drivers/staging/comedi/drivers/adv_pci1710.c
@@ -52,17 +52,8 @@ Configuration options:
* correct channel number on every 12 bit
* sample */
-#undef PCI171X_EXTDEBUG
-
#define DRV_NAME "adv_pci1710"
-#undef DPRINTK
-#ifdef PCI171X_EXTDEBUG
-#define DPRINTK(fmt, args...) printk(fmt, ## args)
-#else
-#define DPRINTK(fmt, args...)
-#endif
-
#define PCI_VENDOR_ID_ADVANTECH0x13fe
/* hardware types of the cards */
@@ -318,7 +309,6 @@ static int pci171x_insn_read_ai(struct comedi_device *dev,
unsigned int idata;
#endif
- DPRINTK("adv_pci1710 EDBG: BGN: pci171x_insn_read_ai(...)\n");
devpriv->CntrlReg &= Control_CNT0;
devpriv->CntrlReg |= Control_SW;/* set software trigger */
outw(devpriv->CntrlReg, dev->iobase + PCI171x_CONTROL);
@@ -327,32 +317,18 @@ static int pci171x_insn_read_ai(struct comedi_device *dev,
setup_channel_list(dev, s, >chanspec, 1, 1);
- DPRINTK("adv_pci1710 A ST=%4x IO=%x\n",
- inw(dev->iobase + PCI171x_STATUS),
- dev->iobase + PCI171x_STATUS);
for (n = 0; n < insn->n; n++) {
outw(0, dev->iobase + PCI171x_SOFTTRG); /* start conversion */
- DPRINTK("adv_pci1710 B n=%d ST=%4x\n", n,
- inw(dev->iobase + PCI171x_STATUS));
/* udelay(1); */
- DPRINTK("adv_pci1710 C n=%d ST=%4x\n", n,
- inw(dev->iobase + PCI171x_STATUS));
timeout = 100;
while (timeout--) {
if (!(inw(dev->iobase + PCI171x_STATUS) & Status_FE))
goto conv_finish;
- if (!(timeout % 10))
- DPRINTK("adv_pci1710 D n=%d tm=%d ST=%4x\n", n,
- timeout,
- inw(dev->iobase + PCI171x_STATUS));
}
comedi_error(dev, "A/D insn timeout");
outb(0, dev->iobase + PCI171x_CLRFIFO);
outb(0, dev->iobase + PCI171x_CLRINT);
data[n] = 0;
- DPRINTK
- ("adv_pci1710 EDBG: END: pci171x_insn_read_ai(...) n=%d\n",
-n);
return -ETIME;
conv_finish:
@@ -373,7 +349,6 @@ conv_finish:
outb(0, dev->iobase + PCI171x_CLRFIFO);
outb(0, dev->iobase + PCI171x_CLRINT);
- DPRINTK("adv_pci1710 EDBG: END: pci171x_insn_read_ai(...) n=%d\n", n);
return n;
}
@@ -584,7 +559,6 @@ static void interrupt_pci1710_every_sample(void *d)
short sampl;
#endif
- DPRINTK("adv_pci1710 EDBG: BGN: interrupt_pci1710_every_sample(...)\n");
m = inw(dev->iobase + PCI171x_STATUS);
if (m & Status_FE) {
printk("comedi%d: A/D FIFO empty (%4x)\n", dev->minor, m);
@@ -605,11 +579,9 @@ static void interrupt_pci1710_every_sample(void *d)
outb(0, dev->iobase + PCI171x_CLRINT); /* clear our INT request */
- DPRINTK("FOR ");
for (; !(inw(dev->iobase + PCI171x_STATUS) & Status_FE);) {
#ifdef PCI171x_PARANOIDCHECK
sampl = inw(dev->iobase + PCI171x_AD_DATA);
- DPRINTK("%04x:", sampl);
if (this_board->cardtype != TYPE_PCI1713)
if ((sampl & 0xf000) !=
devpriv->act_chanlist[s->async->cur_chan]) {
@@ -626,8 +598,6 @@ static void interrupt_pci1710_every_sample(void *d)
comedi_event(dev, s);
return;
}
- DPRINTK("%8d %2d %8d~", s->async->buf_int_ptr,
- s->async->cur_chan, s->async->buf_int_count);
comedi_buf_put(s->async, sampl & 0x0fff);
#else
comedi_buf_put(s->async,
@@ -641,11 +611,6 @@ static void interrupt_pci1710_every_sample(void *d)
if (s->async->cur_chan == 0) { /* one scan done */
devpriv->ai_act_scan++;
- DPRINTK
- ("adv_pci1710 EDBG: EOS1 bic %d bip %d buc %d bup
%d\n",
-s->async->buf_int_count, s->async->buf_int_ptr,
-s->async->buf_user_count, s->async->buf_user_ptr);
-
[PATCH 00/20] staging: comedi: update comedi pci drivers part 2
Another round of updates to the comedi pci drivers. * remove function trace messages * remove devpriv and thisboard type macros * cleanup the boardinfo * remove forward declarations * use attach_pci and remove legacy attach (when possible) * misc. other changes H Hartley Sweeten (20): staging: comedi: adv_pci1710: remove function trace messages staging: comedi: adv_pci1710: remove devpriv and this_board macros staging: comedi: adv_pci1710: convert boardinfo initialization to C99 format staging: comedi: adv_pci1710: remove '0' and 'NULL' boardinfo data staging: comedi: adv_pci1710: remove forward declarations staging: comedi: adv_pci1723: remove function trace messages staging: comedi: adv_pci1723: remove devpriv and this_board macros staging: comedi: adv_pci1723: remove range_pci1723 staging: comedi: adv_pci1723: fix initial dio subdevice state and io_bits staging: comedi: adv_pci1723: remove boardinfo staging: comedi: adv_pci1723: use attach_pci callback staging: comedi: adv_pci1723: cleanup card reset staging: comedi: adv_pci_dio: remove function trace messages staging: comedi: adv_pci_dio: remove devpriv and this_board macros staging: comedi: adv_pci_dio: use attach_pci callback staging: comedi: adv_pci_dio: convert boardinfo initialization to C99 format staging: comedi: adv_pci_dio: remove '0' boardinfo data staging: comedi: adv_pci_dio: add the number of subdevices to the boardinfo staging: comedi: adv_pci_dio: simplify the 'detach' staging: comedi: adv_pci_dio: fix bug in 'detach' drivers/staging/comedi/drivers/adv_pci1710.c | 590 +-- drivers/staging/comedi/drivers/adv_pci1723.c | 222 +++--- drivers/staging/comedi/drivers/adv_pci_dio.c | 428 +-- 3 files changed, 535 insertions(+), 705 deletions(-) -- 1.7.11 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: unable to handle kernel paging request in usb_match_id()
On Fri, Aug 17, 2012 at 10:42 PM, Greg Kroah-Hartman wrote: > On Fri, Aug 17, 2012 at 10:38:16AM -0400, Alan Stern wrote: >> On Fri, 17 Aug 2012, Ming Lei wrote: >> >> > But, if HOTPLUG is not enabled, should device_add() trigger driver probe >> > further after kernel init is completed? Or even devices should be allowed >> > to add into system? >> >> Indeed, does it make any sense to have USB support at all if HOTPLUG >> isn't enabled? Should USB select HOTPLUG? > > Well, a long time ago people wanted to use USB but not have HOTPLUG > enabled in their systems for various (odd) embedded systems. As it's > pretty hard to even turn off HOTPLUG these days, I'd be more likely to > just remove CONFIG_HOTPLUG entirely given the dynamic nature of almost > all systems. It should make sense, otherwise all device id table should not use __devinit* markings. There are lots of pci driver usage on it. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 2/3] PM / Sleep: introduce dpm_for_each_dev
On Sat, Aug 18, 2012 at 6:02 AM, Rafael J. Wysocki wrote: > On Friday, August 17, 2012, Ming Lei wrote: >> +void dpm_for_each_dev(void *data, void (*fn)(struct device *, void *)) > > Is this function actually used more than once? At least now, it is called each time before system sleep. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] ata: Updates for pata_octeon_cf driver.
On 08/17/2012 07:54 PM, David Daney wrote: From: David Daney The main update is conversion to device tree. Now the the OCTEON device tree prerequisites are upstream, we can convert the pata_octeon_cf driver. The second change allows the driver to function when the kernel is built for little-endian operation. The only real change in the MIPS portion of the tree is deletion of crap. There is a dependence on patches Ralf has queued in linux-next so it may be best to merge via the MIPS tree (as pata_octeon_cf only exists in MIPS based OCTEON SOCs). But the ata tree would be fine by me too. In any even we may need some cross sub-system Acked-bys. David Daney (2): MIPS/OCTEON/ata: Convert pata_octeon_cf.c to use device tree. ata: pata_octeon_cf: Use correct byte order for DMA in when built little-endian. arch/mips/cavium-octeon/octeon-irq.c | 1 - arch/mips/cavium-octeon/octeon-platform.c | 102 -- arch/mips/include/asm/mach-cavium-octeon/irq.h | 1 - arch/mips/include/asm/octeon/octeon.h | 7 - drivers/ata/pata_octeon_cf.c | 423 + 5 files changed, 288 insertions(+), 246 deletions(-) patches 1 and 2 are Acked-by: Jeff Garzik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] driver-core: Shut up dev_dbg_reatelimited() without DEBUG
On 08/17/2012 09:04 AM, Hiroshi Doyu wrote:
dev_dbg_reatelimited() without DEBUG printed "217078 callbacks
suppressed". This shouldn't print anything without DEBUG.
Signed-off-by: Hiroshi Doyu
Reported-by: Antti Palosaari
---
include/linux/device.h |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/include/linux/device.h b/include/linux/device.h
index eb945e1..d4dc26e 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -962,9 +962,13 @@ do {
\
dev_level_ratelimited(dev_notice, dev, fmt, ##__VA_ARGS__)
#define dev_info_ratelimited(dev, fmt, ...) \
dev_level_ratelimited(dev_info, dev, fmt, ##__VA_ARGS__)
+#if defined(DEBUG)
#define dev_dbg_ratelimited(dev, fmt, ...)\
dev_level_ratelimited(dev_dbg, dev, fmt, ##__VA_ARGS__)
-
+#else
+#define dev_dbg_ratelimited(dev, fmt, ...) \
+ no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
+#endif
/*
* Stupid hackaround for existing uses of non-printk uses dev_info
*
NACK. I don't think that's correct behavior. After that patch it kills
all output of dev_dbg_ratelimited(). If I use dynamic debugs and order
debugs, I expect to see debugs as earlier.
I did test module in order to demonstrate problem. Here it is:
http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/dev_dbg_ratelimited
There is also file named: test_results.txt
It contains 4 test cases:
1) without that patch & without module dynamic debug
2) without that patch & module dynamic debug ordered
3) with that patch & without module dynamic debug
4) with that patch & module dynamic debug ordered
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PULL REQUEST] md: 2 patches, both heading for -stable
The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) are available in the git repository at: git://neil.brown.name/md/ tags/md-3.6-fixes for you to fetch changes up to e0ee778528bbaad28a5c69d2e219269a3a096607: md/raid10: fix problem with on-stack allocation of r10bio structure. (2012-08-18 09:51:42 +1000) 2 fixes for md, tagged for -stable NeilBrown (2): md: Don't truncate size at 4TB for RAID0 and Linear md/raid10: fix problem with on-stack allocation of r10bio structure. drivers/md/md.c | 9 ++--- drivers/md/raid10.c | 30 +++--- drivers/md/raid10.h | 2 +- 3 files changed, 26 insertions(+), 15 deletions(-) Thanks, NeilBrown signature.asc Description: PGP signature
Re: Repeated fork() causes SLAB to grow without bound
On Thu, Aug 16, 2012 at 02:58:45PM -0400, Rik van Riel wrote:
> Oh dear.
>
> Basically, what happens is that at fork time, a new
> "level" is created for the anon_vma hierarchy. This
> works great for normal forking daemons, since the
> parent process just keeps running, and forking off
> children.
>
> Look at anon_vma_fork() in mm/rmap.c for the details.
>
> Having each child become the new parent, and the
> previous parent exit, can result in an "infinite"
> stack of anon_vmas.
>
> Now, the parent anon_vma we cannot get rid of,
> because that is where the anon_vma lock lives.
>
> However, in your case you have many more anon_vma
> levels than you have processes!
>
> I wonder if it may be possible to fix your bug
> by adding a refcount to the struct anon_vma,
> one count for each VMA that is directly attached
> to the anon_vma (ie. vma->anon_vma == anon_vma),
> and one for each page that points to the anon_vma.
>
> If the reference count on an anon_vma reaches 0,
> we can skip that anon_vma in anon_vma_clone, and
> the child process should not get that anon_vma.
>
> A scheme like that may be enough to avoid the trouble
> you are running into.
>
> Does this sound realistic?
Based on your comments, I came up with the following patch. It boots
and the anon_vma/anon_vma_chain SLAB usage is stable, but I don't know
if I've overlooked something. I'm not a kernel hacker.
--- include/linux/rmap.h.ORIG 2011-08-05 04:59:21.0 +
+++ include/linux/rmap.h2012-08-16 22:52:25.0 +
@@ -35,6 +35,7 @@ struct anon_vma {
* anon_vma if they are the last user on release
*/
atomic_t refcount;
+ atomic_t pagecount;
/*
* NOTE: the LSB of the head.next is set by
--- mm/rmap.c.ORIG 2011-08-05 04:59:21.0 +
+++ mm/rmap.c 2012-08-17 23:55:13.0 +
@@ -85,6 +85,7 @@ static inline struct anon_vma *anon_vma_
static inline void anon_vma_free(struct anon_vma *anon_vma)
{
VM_BUG_ON(atomic_read(_vma->refcount));
+ VM_BUG_ON(atomic_read(_vma->pagecount));
/*
* Synchronize against page_lock_anon_vma() such that
@@ -176,6 +177,7 @@ int anon_vma_prepare(struct vm_area_stru
spin_lock(>page_table_lock);
if (likely(!vma->anon_vma)) {
vma->anon_vma = anon_vma;
+ atomic_inc(_vma->pagecount);
avc->anon_vma = anon_vma;
avc->vma = vma;
list_add(>same_vma, >anon_vma_chain);
@@ -262,7 +264,10 @@ int anon_vma_clone(struct vm_area_struct
}
anon_vma = pavc->anon_vma;
root = lock_anon_vma_root(root, anon_vma);
- anon_vma_chain_link(dst, avc, anon_vma);
+ if (!atomic_read(_vma->pagecount))
+ anon_vma_chain_free(avc);
+ else
+ anon_vma_chain_link(dst, avc, anon_vma);
}
unlock_anon_vma_root(root);
return 0;
@@ -314,6 +319,7 @@ int anon_vma_fork(struct vm_area_struct
get_anon_vma(anon_vma->root);
/* Mark this anon_vma as the one where our new (COWed) pages go. */
vma->anon_vma = anon_vma;
+ atomic_set(_vma->pagecount, 1);
anon_vma_lock(anon_vma);
anon_vma_chain_link(vma, avc, anon_vma);
anon_vma_unlock(anon_vma);
@@ -341,6 +347,8 @@ void unlink_anon_vmas(struct vm_area_str
root = lock_anon_vma_root(root, anon_vma);
list_del(>same_anon_vma);
+ if (vma->anon_vma == anon_vma)
+ atomic_dec(_vma->pagecount);
/*
* Leave empty anon_vmas on the list - we'll need
@@ -375,6 +383,7 @@ static void anon_vma_ctor(void *data)
mutex_init(_vma->mutex);
atomic_set(_vma->refcount, 0);
+ atomic_set(_vma->pagecount, 0);
INIT_LIST_HEAD(_vma->head);
}
@@ -996,6 +1005,7 @@ static void __page_set_anon_rmap(struct
if (!exclusive)
anon_vma = anon_vma->root;
+ atomic_inc(_vma->pagecount);
anon_vma = (void *) anon_vma + PAGE_MAPPING_ANON;
page->mapping = (struct address_space *) anon_vma;
page->index = linear_page_index(vma, address);
@@ -1142,6 +1152,11 @@ void page_remove_rmap(struct page *page)
if (unlikely(PageHuge(page)))
return;
if (PageAnon(page)) {
+ struct anon_vma *anon_vma;
+
+ anon_vma = page_anon_vma(page);
+ if (anon_vma)
+ atomic_dec(_vma->pagecount);
mem_cgroup_uncharge_page(page);
if (!PageTransHuge(page))
__dec_zone_page_state(page, NR_ANON_PAGES);
@@ -1747,6 +1762,7 @@ static void __hugepage_set_anon_rmap(str
if (!exclusive)
anon_vma = anon_vma->root;
+ atomic_inc(_vma->pagecount);
[PATCH][GIT PULL][v3.6] tracing/syscalls: Fix perf syscall tracing when syscall_nr == -1
Ingo,
Please pull the latest tip/perf/urgent tree, which can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
tip/perf/urgent
Head SHA1: 60916a9382e88fbf5e54fd36a3e658efd7ab7bed
Will Deacon (1):
tracing/syscalls: Fix perf syscall tracing when syscall_nr == -1
kernel/trace/trace_syscalls.c |4
1 file changed, 4 insertions(+)
---
commit 60916a9382e88fbf5e54fd36a3e658efd7ab7bed
Author: Will Deacon
Date: Thu Aug 16 18:14:14 2012 +0100
tracing/syscalls: Fix perf syscall tracing when syscall_nr == -1
syscall_get_nr can return -1 in the case that the task is not executing
a system call.
This patch fixes perf_syscall_{enter,exit} to check that the syscall
number is valid before using it as an index into a bitmap.
Link:
http://lkml.kernel.org/r/1345137254-7377-1-git-send-email-will.dea...@arm.com
Cc: Jason Baron
Cc: Wade Farnsworth
Cc: Frederic Weisbecker
Signed-off-by: Will Deacon
Signed-off-by: Steven Rostedt
diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
index 60e4d78..6b245f64 100644
--- a/kernel/trace/trace_syscalls.c
+++ b/kernel/trace/trace_syscalls.c
@@ -506,6 +506,8 @@ static void perf_syscall_enter(void *ignore, struct pt_regs
*regs, long id)
int size;
syscall_nr = syscall_get_nr(current, regs);
+ if (syscall_nr < 0)
+ return;
if (!test_bit(syscall_nr, enabled_perf_enter_syscalls))
return;
@@ -580,6 +582,8 @@ static void perf_syscall_exit(void *ignore, struct pt_regs
*regs, long ret)
int size;
syscall_nr = syscall_get_nr(current, regs);
+ if (syscall_nr < 0)
+ return;
if (!test_bit(syscall_nr, enabled_perf_exit_syscalls))
return;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] MIPS/OCTEON/ata: Convert pata_octeon_cf.c to use device tree.
From: David Daney
The patch needs to eliminate the definition of OCTEON_IRQ_BOOTDMA so
that the device tree code can map the interrupt, so in order to not
temporarily break things, we do a single patch to both the interrupt
registration code and the pata_octeon_cf driver.
Also rolled in is a conversion to use hrtimers and corrections to the
timing calculations.
Signed-off-by: David Daney
---
arch/mips/cavium-octeon/octeon-irq.c | 1 -
arch/mips/cavium-octeon/octeon-platform.c | 102 --
arch/mips/include/asm/mach-cavium-octeon/irq.h | 1 -
arch/mips/include/asm/octeon/octeon.h | 7 -
drivers/ata/pata_octeon_cf.c | 419 +
5 files changed, 284 insertions(+), 246 deletions(-)
diff --git a/arch/mips/cavium-octeon/octeon-irq.c
b/arch/mips/cavium-octeon/octeon-irq.c
index 274cd4f..5dcb88c 100644
--- a/arch/mips/cavium-octeon/octeon-irq.c
+++ b/arch/mips/cavium-octeon/octeon-irq.c
@@ -1213,7 +1213,6 @@ static void __init octeon_irq_init_ciu(void)
octeon_irq_force_ciu_mapping(ciu_domain, i + OCTEON_IRQ_TIMER0,
0, i + 52);
octeon_irq_force_ciu_mapping(ciu_domain, OCTEON_IRQ_USB0, 0, 56);
- octeon_irq_force_ciu_mapping(ciu_domain, OCTEON_IRQ_BOOTDMA, 0, 63);
/* CIU_1 */
for (i = 0; i < 16; i++)
diff --git a/arch/mips/cavium-octeon/octeon-platform.c
b/arch/mips/cavium-octeon/octeon-platform.c
index 0938df1..3c1b625 100644
--- a/arch/mips/cavium-octeon/octeon-platform.c
+++ b/arch/mips/cavium-octeon/octeon-platform.c
@@ -24,108 +24,6 @@
#include
#include
-static struct octeon_cf_data octeon_cf_data;
-
-static int __init octeon_cf_device_init(void)
-{
- union cvmx_mio_boot_reg_cfgx mio_boot_reg_cfg;
- unsigned long base_ptr, region_base, region_size;
- struct platform_device *pd;
- struct resource cf_resources[3];
- unsigned int num_resources;
- int i;
- int ret = 0;
-
- /* Setup octeon-cf platform device if present. */
- base_ptr = 0;
- if (octeon_bootinfo->major_version == 1
- && octeon_bootinfo->minor_version >= 1) {
- if (octeon_bootinfo->compact_flash_common_base_addr)
- base_ptr =
- octeon_bootinfo->compact_flash_common_base_addr;
- } else {
- base_ptr = 0x1d000800;
- }
-
- if (!base_ptr)
- return ret;
-
- /* Find CS0 region. */
- for (i = 0; i < 8; i++) {
- mio_boot_reg_cfg.u64 = cvmx_read_csr(CVMX_MIO_BOOT_REG_CFGX(i));
- region_base = mio_boot_reg_cfg.s.base << 16;
- region_size = (mio_boot_reg_cfg.s.size + 1) << 16;
- if (mio_boot_reg_cfg.s.en && base_ptr >= region_base
- && base_ptr < region_base + region_size)
- break;
- }
- if (i >= 7) {
- /* i and i + 1 are CS0 and CS1, both must be less than 8. */
- goto out;
- }
- octeon_cf_data.base_region = i;
- octeon_cf_data.is16bit = mio_boot_reg_cfg.s.width;
- octeon_cf_data.base_region_bias = base_ptr - region_base;
- memset(cf_resources, 0, sizeof(cf_resources));
- num_resources = 0;
- cf_resources[num_resources].flags = IORESOURCE_MEM;
- cf_resources[num_resources].start = region_base;
- cf_resources[num_resources].end = region_base + region_size - 1;
- num_resources++;
-
-
- if (!(base_ptr & 0xul)) {
- /*
-* Boot loader signals availability of DMA (true_ide
-* mode) by setting low order bits of base_ptr to
-* zero.
-*/
-
- /* Assume that CS1 immediately follows. */
- mio_boot_reg_cfg.u64 =
- cvmx_read_csr(CVMX_MIO_BOOT_REG_CFGX(i + 1));
- region_base = mio_boot_reg_cfg.s.base << 16;
- region_size = (mio_boot_reg_cfg.s.size + 1) << 16;
- if (!mio_boot_reg_cfg.s.en)
- goto out;
-
- cf_resources[num_resources].flags = IORESOURCE_MEM;
- cf_resources[num_resources].start = region_base;
- cf_resources[num_resources].end = region_base + region_size - 1;
- num_resources++;
-
- octeon_cf_data.dma_engine = 0;
- cf_resources[num_resources].flags = IORESOURCE_IRQ;
- cf_resources[num_resources].start = OCTEON_IRQ_BOOTDMA;
- cf_resources[num_resources].end = OCTEON_IRQ_BOOTDMA;
- num_resources++;
- } else {
- octeon_cf_data.dma_engine = -1;
- }
-
- pd = platform_device_alloc("pata_octeon_cf", -1);
- if (!pd) {
- ret = -ENOMEM;
- goto out;
- }
- pd->dev.platform_data = _cf_data;
-
- ret =
[PATCH 2/2] ata: pata_octeon_cf: Use correct byte order for DMA in when built little-endian.
From: David Daney We need to set the 'endian' bit in this case. Signed-off-by: David Daney --- drivers/ata/pata_octeon_cf.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/ata/pata_octeon_cf.c b/drivers/ata/pata_octeon_cf.c index 652d035..4e1194b 100644 --- a/drivers/ata/pata_octeon_cf.c +++ b/drivers/ata/pata_octeon_cf.c @@ -20,6 +20,7 @@ #include #include +#include #include /* @@ -589,6 +590,9 @@ static void octeon_cf_dma_start(struct ata_queued_cmd *qc) /* Set the direction of the DMA */ mio_boot_dma_cfg.u64 = 0; +#ifdef __LITTLE_ENDIAN + mio_boot_dma_cfg.s.endian = 1; +#endif mio_boot_dma_cfg.s.en = 1; mio_boot_dma_cfg.s.rw = ((qc->tf.flags & ATA_TFLAG_WRITE) != 0); -- 1.7.11.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] ata: Updates for pata_octeon_cf driver.
From: David Daney The main update is conversion to device tree. Now the the OCTEON device tree prerequisites are upstream, we can convert the pata_octeon_cf driver. The second change allows the driver to function when the kernel is built for little-endian operation. The only real change in the MIPS portion of the tree is deletion of crap. There is a dependence on patches Ralf has queued in linux-next so it may be best to merge via the MIPS tree (as pata_octeon_cf only exists in MIPS based OCTEON SOCs). But the ata tree would be fine by me too. In any even we may need some cross sub-system Acked-bys. David Daney (2): MIPS/OCTEON/ata: Convert pata_octeon_cf.c to use device tree. ata: pata_octeon_cf: Use correct byte order for DMA in when built little-endian. arch/mips/cavium-octeon/octeon-irq.c | 1 - arch/mips/cavium-octeon/octeon-platform.c | 102 -- arch/mips/include/asm/mach-cavium-octeon/irq.h | 1 - arch/mips/include/asm/octeon/octeon.h | 7 - drivers/ata/pata_octeon_cf.c | 423 + 5 files changed, 288 insertions(+), 246 deletions(-) -- 1.7.11.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] unifdef: set a secure umask before calling mkstemp()
Jesper Juhl wrote: > In newer glibc's (versions > 2.06) reasonably secure permissions of > 0600 are used when creating a temporary file with mkstemp(). But for > older glibc's (versions <= 2.06) 0666 is used which is not secure. Thanks for your suggestion! I'm afraid I prefer not to make the change. Unifdef is only using mkstemp as a convenient way to open a file with a non-clashing name. It isn't trying to be secure, so it's OK just to rely on the user's umask. And I find it hard to care about a bug that was fixed 15 years ago. I'm also trying to reduce the unixisms in the program for portability reasons and this is the most awkward part :-/ Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On 08/17/2012 05:21 PM, Dan Magenheimer wrote: >> From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] >> Subject: Re: [PATCH 0/4] promote zcache from staging >> >> On 08/09/2012 03:20 PM, Dan Magenheimer wrote >>> I also wonder if you have anything else unusual in your >>> test setup, such as a fast swap disk (mine is a partition >>> on the same rotating disk as source and target of the kernel build, >>> the default install for a RHEL6 system)? >> >> I'm using a normal SATA HDD with two partitions, one for >> swap and the other an ext3 filesystem with the kernel source. >> >>> Or have you disabled cleancache? >> >> Yes, I _did_ disable cleancache. I could see where having >> cleancache enabled could explain the difference in results. > > Sorry to beat a dead horse, but I meant to report this > earlier in the week and got tied up by other things. > > I finally got my test scaffold set up earlier this week > to try to reproduce my "bad" numbers with the RHEL6-ish > config file. > > I found that with "make -j28" and "make -j32" I experienced > __DATA CORRUPTION__. This was repeatable. I actually hit this for the first time a few hours ago when I was running performance for your rewrite. I didn't know what to make of it yet. The 24-thread kernel build failed when both frontswap and cleancache were enabled. > The type of error led me to believe that the problem was > due to concurrency of cleancache reclaim. I did not try > with cleancache disabled to prove/support this theory > but it is consistent with the fact that you (Seth) have not > seen a similar problem and has disabled cleancache. > > While this problem is most likely in my code and I am > suitably chagrined, it re-emphasizes the fact that > the current zcache in staging is 20-month old "demo" > code. The proposed new zcache codebase handles concurrency > much more effectively. I imagine this can be solved without rewriting the entire codebase. If your new code contains a fix for this, can we just pull it as a single patch? Seth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 32/37] drm/i915: correctly order the ring init sequence
On Fri, Aug 17, 2012 at 04:03:15AM +0100, Ben Hutchings wrote: > 3.2-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Daniel Vetter > > commit 0d8957c8a90bbb5d34fab9a304459448a5131e06 upstream. > > We may only start to set up the new register values after having > confirmed that the ring is truely off. Otherwise the hw might lose the > newly written register values. This is caught later on in the init > sequence, when we check whether the register writes have stuck. > > Reviewed-by: Jani Nikula > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522 > Tested-by: Yang Guang > Signed-off-by: Daniel Vetter > Signed-off-by: Ben Hutchings [...] With this commit on 3.2, i915 fails to initialize on a G41 based machine I have here: [ 36.894261] i915 :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 36.894265] i915 :00:02.0: setting latency timer to 64 [ 36.933118] mtrr: type mismatch for d000,1000 old: write-back new: write-combining [ 36.933121] [drm] MTRR allocation failed. Graphics performance may suffer. [ 36.933467] i915 :00:02.0: irq 42 for MSI/MSI-X [ 36.933471] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 36.933472] [drm] Driver supports precise vblank timestamp query. [ 36.933498] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 36.969669] [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head 1074 tail start 1000 [ 36.969763] vga_switcheroo: disabled [ 36.969765] [drm:i915_driver_load] *ERROR* failed to init modeset [ 36.987444] i915 :00:02.0: PCI INT A disabled [ 36.987453] i915: probe of :00:02.0 failed with error -5 Taking a look at it, I suspected of a timing issue, especially looking at this commit, which isn't on 3.2: commit f01db988ef6f6c70a6cc36ee71e4a98a68901229 Author: Sean Paul Date: Fri Mar 16 12:43:22 2012 -0400 drm/i915: Add wait_for in init_ring_common And picking it made the issue go away, so the extra delay helped and is needed with 0d8957c8a90bbb5d34fab9a304459448a5131e06 applied here. -- []'s Herton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 14/17] input: RMI4 F30 GPIO/LED control
Signed-off-by: Christopher Heiny
Cc: Dmitry Torokhov
Cc: Linus Walleij
Cc: Naveen Kumar Gaddipati
Cc: Joeri de Gram
Acked-by: Jean Delvare
---
drivers/input/rmi4/rmi_f30.c | 1247 ++
1 files changed, 1247 insertions(+), 0 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f30.c b/drivers/input/rmi4/rmi_f30.c
new file mode 100644
index 000..4bc2932
--- /dev/null
+++ b/drivers/input/rmi4/rmi_f30.c
@@ -0,0 +1,1247 @@
+/*
+ * Copyright (c) 2012 Synaptics Incorporated
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#define FUNCTION_DATA rmi_fn_30_data
+#define FNUM 30
+
+#include
+#include
+#include
+#include
+#include "rmi_driver.h"
+
+
+#define MAX_LEN 256
+
+/* data specific to fn $30 that needs to be kept around */
+union f30_query {
+ struct {
+ u8 extended_patterns:1;
+ u8 has_mappable_buttons:1;
+ u8 has_led:1;
+ u8 has_gpio:1;
+ u8 has_haptic:1;
+ u8 has_gpio_driver_control:1;
+ u8 gpio_led_count:5;
+ };
+ struct {
+ u8 regs[2];
+ u16 address;
+ };
+};
+
+struct f30_gpio_ctrl_0n {
+ u8 led_sel;
+};
+
+struct f30_gpio_ctrl_0 {
+ struct f30_gpio_ctrl_0n *regs;
+ u16 address;
+ u8 length;
+};
+
+union f30_gpio_ctrl_1 {
+ struct {
+ u8 gpio_debounce:1;
+ u8 reserved:3;
+ u8 halt:1;
+ u8 halted:1;
+ u8 reserved2:2;
+ };
+ struct {
+ u8 regs[1];
+ u16 address;
+ };
+};
+
+struct f30_gpio_ctrl_2n {
+ u8 dir;
+};
+
+struct f30_gpio_ctrl_2 {
+ struct f30_gpio_ctrl_2n *regs;
+ u16 address;
+ u8 length;
+};
+
+struct f30_gpio_ctrl_3n {
+ u8 gpiodata;
+};
+
+struct f30_gpio_ctrl_3 {
+ struct f30_gpio_ctrl_3n *regs;
+ u16 address;
+ u8 length;
+};
+
+struct f30_gpio_ctrl_4n {
+ u8 led_act;
+};
+
+struct f30_gpio_ctrl_4 {
+ struct f30_gpio_ctrl_4n *regs;
+ u16 address;
+ u8 length;
+};
+
+struct f30_gpio_ctrl_5n {
+ u8 ramp_period_a;
+ u8 ramp_period_b;
+};
+
+struct f30_gpio_ctrl_5 {
+ struct f30_gpio_ctrl_5n *regs;
+ u16 address;
+ u8 length;
+};
+
+union f30_gpio_ctrl_6n {
+ struct {
+ u8 reserved:1;
+ u8 SPCTRL:3;
+ u8 STRPD:1;
+ u8 reserved2:1;
+ u8 STRPU:1;
+ u8 reserved3:1;
+ };
+ struct {
+ u8 brightness:4;
+ u8 pattern:4;
+ };
+};
+
+struct f30_gpio_ctrl_6 {
+ union f30_gpio_ctrl_6n *regs;
+ u16 address;
+ u8 length;
+};
+
+struct f30_gpio_ctrl_7n {
+ u8 capacity_btn_nbr:5;
+ u8 valid:1;
+ u8 invert:1;
+ u8 open_drain:1;
+};
+
+struct f30_gpio_ctrl_7 {
+ struct f30_gpio_ctrl_7n *regs;
+ u16 address;
+ u8 length;
+};
+
+struct f30_gpio_ctrl_8n {
+ u8 gpio_ctrl8_0;
+ u8 gpio_ctrl8_1;
+};
+
+struct f30_gpio_ctrl_8 {
+ struct f30_gpio_ctrl_8n *regs;
+ u16 address;
+ u8 length;
+};
+
+union f30_gpio_ctrl_9 {
+ struct {
+ u8 haptic_duration;
+ };
+ struct {
+ u8 regs[1];
+ u16 address;
+ };
+};
+
+struct f30_control {
+ struct f30_gpio_ctrl_0 *reg_0;
+ union f30_gpio_ctrl_1 *reg_1;
+ struct f30_gpio_ctrl_2 *reg_2;
+ struct f30_gpio_ctrl_3 *reg_3;
+ struct f30_gpio_ctrl_4 *reg_4;
+ struct f30_gpio_ctrl_5 *reg_5;
+ struct f30_gpio_ctrl_6 *reg_6;
+ struct f30_gpio_ctrl_7 *reg_7;
+ struct f30_gpio_ctrl_8 *reg_8;
+ union f30_gpio_ctrl_9 *reg_9;
+};
+
+struct f30_data_0n {
+ u8 gpi_led_data:1;
+};
+
+struct f30_data_0 {
+ struct f30_data_0n *regs;
+ u16 address;
+ u8 length;
+};
+
+struct f30_data {
+ struct f30_data_0 *datareg_0;
+ u16 address;
+ u8 length;
+};
+
+struct rmi_fn_30_data {
+ union f30_query query;
+ struct f30_data data;
+ struct f30_control control;
+ unsigned char gpioled_count;
+ unsigned char gpioled_bitmask_size;
+ unsigned char gpioled_byte_size;
+ unsigned char
[RFC PATCH 12/17] input: RMI4 F1A simple capacitive buttons
Signed-off-by: Christopher Heiny
Cc: Dmitry Torokhov
Cc: Linus Walleij
Cc: Naveen Kumar Gaddipati
Cc: Joeri de Gram
Acked-by: Jean Delvare
---
drivers/input/rmi4/rmi_f1a.c | 1025 ++
1 files changed, 1025 insertions(+), 0 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f1a.c b/drivers/input/rmi4/rmi_f1a.c
new file mode 100644
index 000..a7cccfa
--- /dev/null
+++ b/drivers/input/rmi4/rmi_f1a.c
@@ -0,0 +1,1025 @@
+/*
+ * Copyright (c) 2012 Synaptics Incorporated
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#define FUNCTION_DATA f1a_data
+#define FNUM 1a
+
+#include
+#include
+#include
+#include
+#include "rmi_driver.h"
+
+#define QUERY_BASE_INDEX 1
+#define MAX_NAME_LEN 256
+#define MAX_BUFFER_LEN 80
+
+#define FILTER_MODE_MIN0
+#define FILTER_MODE_MAX3
+#define MULTI_BUTTON_REPORT_MIN0
+#define MULTI_BUTTON_REPORT_MAX3
+#define TX_RX_BUTTON_MIN 0
+#define TX_RX_BUTTON_MAX 255
+#define THREADHOLD_BUTTON_MIN 0
+#define THREADHOLD_BUTTON_MAX 255
+#define RELEASE_THREADHOLD_BUTTON_MIN 0
+#define RELEASE_THREADHOLD_BUTTON_MAX 255
+#define STRONGEST_BUTTON_HYSTERESIS_MIN0
+#define STRONGEST_BUTTON_HYSTERESIS_MAX255
+#define FILTER_STRENGTH_MIN0
+#define FILTER_STRENGTH_MAX255
+
+union f1a_0d_query {
+ struct {
+ u8 max_button_count:3;
+ u8 reserved:5;
+
+ u8 has_general_control:1;
+ u8 has_interrupt_enable:1;
+ u8 has_multibutton_select:1;
+ u8 has_tx_rx_map:1;
+ u8 has_perbutton_threshold:1;
+ u8 has_release_threshold:1;
+ u8 has_strongestbtn_hysteresis:1;
+ u8 has_filter_strength:1;
+ } __attribute__((__packed__));
+ struct {
+ u8 regs[2];
+ u16 address;
+ } __attribute__((__packed__));
+};
+
+union f1a_0d_control_0 {
+ struct {
+ u8 multibutton_report:2;
+ u8 filter_mode:2;
+ } __attribute__((__packed__));
+ struct {
+ u8 regs[1];
+ u16 address;
+ } __attribute__((__packed__));
+};
+
+struct f1a_0d_control_1n {
+ u8 interrupt_enabled_button;
+};
+
+struct f1a_0d_control_1 {
+ struct f1a_0d_control_1n *regs;
+ u16 address;
+ u8 length;
+} __attribute__((__packed__));
+
+struct f1a_0d_control_2n {
+ u8 multi_button;
+};
+
+struct f1a_0d_control_2 {
+ struct f1a_0d_control_2n *regs;
+ u16 address;
+ u8 length;
+} __attribute__((__packed__));
+
+struct f1a_0d_control_3_4n {
+ u8 transmitterbtn;
+ u8 receiverbtn;
+} __attribute__((__packed__));
+
+struct f1a_0d_control_3_4 {
+ struct f1a_0d_control_3_4n *regs;
+ u16 address;
+ u8 length;
+} __attribute__((__packed__));
+
+struct f1a_0d_control_5n {
+ u8 threshold_button;
+};
+
+struct f1a_0d_control_5 {
+ struct f1a_0d_control_5n *regs;
+ u16 address;
+ u8 length;
+} __attribute__((__packed__));
+
+union f1a_0d_control_6 {
+ struct {
+ u8 button_release_threshold;
+ };
+ struct {
+ u8 regs[1];
+ u16 address;
+ } __attribute__((__packed__));
+};
+
+union f1a_0d_control_7 {
+ struct {
+ u8 strongest_button_hysteresis;
+ };
+ struct {
+ u8 regs[1];
+ u16 address;
+ } __attribute__((__packed__));
+};
+
+union f1a_0d_control_8 {
+ struct {
+ u8 filter_strength;
+ };
+ struct {
+ u8 regs[1];
+ u16 address;
+ } __attribute__((__packed__));
+};
+
+struct f1a_0d_control {
+ union f1a_0d_control_0 *reg_0;
+ struct f1a_0d_control_1 *reg_1;
+ struct f1a_0d_control_2 *reg_2;
+ struct f1a_0d_control_3_4 *reg_3_4;
+ struct f1a_0d_control_5 *reg_5;
+ union f1a_0d_control_6 *reg_6;
+ union f1a_0d_control_7 *reg_7;
+ union f1a_0d_control_8 *reg_8;
+};
+
+/* data specific to fn
[RFC PATCH 16/17] input: RMI4 F41 Active pen 2D input
Signed-off-by: Christopher Heiny
Cc: Dmitry Torokhov
Cc: Linus Walleij
Cc: Naveen Kumar Gaddipati
Cc: Joeri de Gram
Acked-by: Jean Delvare
---
drivers/input/rmi4/rmi_f41.c | 1020 ++
1 files changed, 1020 insertions(+), 0 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f41.c b/drivers/input/rmi4/rmi_f41.c
new file mode 100644
index 000..1bac4e3
--- /dev/null
+++ b/drivers/input/rmi4/rmi_f41.c
@@ -0,0 +1,1020 @@
+/*
+ * Copyright (c) 2012 Synaptics Incorporated
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#define FUNCTION_DATA rmi_fn_41_data
+#define FNUM 41
+
+
+#include
+#include
+#include
+#include
+#include "rmi_driver.h"
+
+#define MAX_STR_LEN 256
+
+union f41_ap_query {
+ struct {
+ /* Query 0 */
+ u8 has_reduced_reporting:1;
+ u8 has_modal_control:1;
+ u8 has_force:1;
+ u8 has_orientation:1;
+ u8 has_serial_number:1;
+ u8 has_battery:1;
+ u8 has_z:1;
+ u8 has_single_tap:1;
+
+ /* Query 1 */
+ u8 number_of_buttons:3;
+ u8 f41_ap_query1_b3__7:5;
+ } __attribute__((__packed__));
+ struct {
+ u8 regs[2];
+ u16 address;
+ } __attribute__((__packed__));
+};
+
+
+union f41_ap_control_0 {
+ struct {
+ /* control 0 */
+ u8 reporting_mode:2;
+ u8 modal_ctrl:1;
+ u8 f41_ap_control0_b3__4:2;
+ u8 single_tap_interrupt_enable:1;
+ u8 in_range_interrupt_enable:1;
+ u8 new_sn_interrupt_enable:1;
+ } __attribute__((__packed__));
+ struct {
+ u8 regs[1];
+ u16 address;
+ } __attribute__((__packed__));
+};
+
+union f41_ap_control_1 {
+ struct {
+ /* control 1 */
+ u8 button_1_interrupt_enable:1;
+ u8 button_2_interrupt_enable:1;
+ u8 button_3_interrupt_enable:1;
+ u8 button_4_interrupt_enable:1;
+ u8 button_5_interrupt_enable:1;
+ u8 button_6_interrupt_enable:1;
+ u8 button_7_interrupt_enable:1;
+ u8 f41_ap_control1_b7:1;
+ } __attribute__((__packed__));
+ struct {
+ u8 regs[1];
+ u16 address;
+ } __attribute__((__packed__));
+};
+
+union f41_ap_control_2__5 {
+ struct {
+ u16 max_x_position;
+ u16 max_y_position;
+ } __attribute__((__packed__));
+ struct {
+ u8 regs[4];
+ u16 address;
+ } __attribute__((__packed__));
+};
+
+union f41_ap_control_6__9 {
+ struct {
+ u16 x_reduced_reporting_distance;
+ u16 y_reduced_reporting_distance;
+ } __attribute__((__packed__));
+ struct {
+ u8 regs[4];
+ u16 address;
+ } __attribute__((__packed__));
+};
+
+union f41_ap_control_10 {
+ struct {
+ u8 max_tap_time;
+ } __attribute__((__packed__));
+ struct {
+ u8 regs[1];
+ u16 address;
+ } __attribute__((__packed__));
+};
+
+struct f41_ap_control {
+ union f41_ap_control_0 *reg_0;
+ union f41_ap_control_1 *reg_1;
+ union f41_ap_control_2__5 *reg_2__5;
+ union f41_ap_control_6__9 *reg_6__9;
+ union f41_ap_control_10 *reg_10;
+};
+
+
+union f41_ap_data_0__3 {
+ struct {
+ /* data 0-1 */
+ u16 x_position;
+
+ /* data 2-3 */
+ u16 y_position;
+ } __attribute__((__packed__));
+ struct {
+ u8 regs[4];
+ } __attribute__((__packed__));
+};
+
+union f41_ap_data_4 {
+ struct {
+ /* data 4 */
+ u8 force;
+ } __attribute__((__packed__));
+ struct {
+ u8 regs[1];
+ } __attribute__((__packed__));
+};
+
+union f41_ap_data_5 {
+ struct {
+ /* data 5 */
+ u8 button_1_state:1;
+ u8 button_2_state:1;
+ u8 button_3_state:1;
+ u8 button_4_state:1;
+ u8 button_5_state:1;
+ u8
[RFC PATCH 15/17] input: RMI4 F34 device reflash
Signed-off-by: Christopher Heiny
Cc: Dmitry Torokhov
Cc: Linus Walleij
Cc: Naveen Kumar Gaddipati
Cc: Joeri de Gram
Acked-by: Jean Delvare
---
drivers/input/rmi4/rmi_f34.c | 917 ++
drivers/input/rmi4/rmi_f34.h | 74
2 files changed, 991 insertions(+), 0 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f34.c b/drivers/input/rmi4/rmi_f34.c
new file mode 100644
index 000..a07f7f9
--- /dev/null
+++ b/drivers/input/rmi4/rmi_f34.c
@@ -0,0 +1,917 @@
+/*
+ * Copyright (c) 2011, 2012 Synaptics Incorporated
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#include
+#include
+#include
+#include
+#include
+#include "rmi_driver.h"
+#include "rmi_f34.h"
+
+#define BLK_SZ_OFF 3
+#define IMG_BLK_CNT_OFF5
+#define CFG_BLK_CNT_OFF7
+
+#define BLK_NUM_OFF 2
+
+/* data specific to fn $34 that needs to be kept around */
+struct rmi_fn_34_data {
+ unsigned char status;
+ unsigned char cmd;
+ unsigned short bootloaderid;
+ unsigned short blocksize;
+ unsigned short imageblockcount;
+ unsigned short configblockcount;
+ unsigned short blocknum;
+ bool inflashprogmode;
+ struct mutex attn_mutex;
+};
+
+static ssize_t rmi_fn_34_status_show(struct device *dev,
+struct device_attribute *attr, char *buf);
+
+
+static ssize_t rmi_fn_34_status_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count);
+
+static ssize_t rmi_fn_34_cmd_show(struct device *dev,
+ struct device_attribute *attr, char *buf);
+
+static ssize_t rmi_fn_34_cmd_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count);
+
+static ssize_t rmi_fn_34_data_read(struct file *data_file, struct kobject
*kobj,
+ struct bin_attribute *attributes,
+ char *buf, loff_t pos, size_t count);
+
+static ssize_t rmi_fn_34_data_write(struct file *data_file,
+ struct kobject *kobj,
+ struct bin_attribute *attributes, char *buf,
+ loff_t pos, size_t count);
+
+static ssize_t rmi_fn_34_bootloaderid_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf);
+
+static ssize_t rmi_fn_34_bootloaderid_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count);
+
+static ssize_t rmi_fn_34_blocksize_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf);
+
+static ssize_t rmi_fn_34_imageblockcount_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf);
+
+static ssize_t rmi_fn_34_configblockcount_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf);
+
+static ssize_t rmi_fn_34_blocknum_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf);
+
+static ssize_t rmi_fn_34_blocknum_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count);
+
+static ssize_t rmi_fn_34_rescanPDT_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count);
+
+
+static int rmi_f34_alloc_memory(struct rmi_function_container *fc);
+
+static void rmi_f34_free_memory(struct rmi_function_container *fc);
+
+static int rmi_f34_initialize(struct rmi_function_container *fc);
+
+static int rmi_f34_config(struct rmi_function_container *fc);
+
+static int rmi_f34_reset(struct rmi_function_container
[RFC PATCH 5/17] input: rmidev character driver for RMI4 sensors
Driver for Synaptics touchscreens using RMI4 protocol.
Signed-off-by: Christopher Heiny
Cc: Dmitry Torokhov
Cc: Linus Walleij
Cc: Naveen Kumar Gaddipati
Cc: Joeri de Gram
Acked-by: Jean Delvare
---
drivers/input/rmi4/rmi_dev.c | 448 ++
1 files changed, 448 insertions(+), 0 deletions(-)
diff --git a/drivers/input/rmi4/rmi_dev.c b/drivers/input/rmi4/rmi_dev.c
new file mode 100644
index 000..080db55
--- /dev/null
+++ b/drivers/input/rmi4/rmi_dev.c
@@ -0,0 +1,448 @@
+/*
+ * Copyright (c) 2011 Synaptics Incorporated
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include "rmi_driver.h"
+
+#define CHAR_DEVICE_NAME "rmi"
+#define DEVICE_CLASS_NAME "rmidev"
+
+#define RMI_CHAR_DEV_TMPBUF_SZ 128
+#define RMI_REG_ADDR_PAGE_SELECT 0xFF
+#define REG_ADDR_LIMIT 0x
+
+struct rmidev_data {
+ /* mutex for file operation*/
+ struct mutex file_mutex;
+ /* main char dev structure */
+ struct cdev main_dev;
+
+ /* pointer to the corresponding RMI4 device. We use this to do */
+ /* read, write, etc. */
+ struct rmi_device *rmi_dev;
+ /* reference count */
+ int ref_count;
+
+ struct class *device_class;
+};
+
+/*store dynamically allocated major number of char device*/
+static int rmidev_major_num;
+
+
+static struct class *rmidev_device_class;
+
+
+/* file operations for RMI char device */
+
+/*
+ * rmidev_llseek: - use to setup register address
+ *
+ * @filp: file structure for seek
+ * @off: offset
+ * if whence == SEEK_SET,
+ * high 16 bits: page address
+ * low 16 bits: register address
+ *
+ * if whence == SEEK_CUR,
+ * offset from current position
+ *
+ * if whence == SEEK_END,
+ * offset from END(0x)
+ *
+ * @whence: SEEK_SET , SEEK_CUR or SEEK_END
+ */
+static loff_t rmidev_llseek(struct file *filp, loff_t off, int whence)
+{
+ loff_t newpos;
+ struct rmidev_data *data = filp->private_data;
+
+ if (IS_ERR(data)) {
+ pr_err("%s: pointer of char device is invalid", __func__);
+ return -EBADF;
+ }
+
+ mutex_lock(&(data->file_mutex));
+
+ switch (whence) {
+ case SEEK_SET:
+ newpos = off;
+ break;
+
+ case SEEK_CUR:
+ newpos = filp->f_pos + off;
+ break;
+
+ case SEEK_END:
+ newpos = REG_ADDR_LIMIT + off;
+ break;
+
+ default:/* can't happen */
+ newpos = -EINVAL;
+ goto clean_up;
+ }
+
+ if (newpos < 0 || newpos > REG_ADDR_LIMIT) {
+ dev_err(>rmi_dev->dev, "newpos 0x%04x is invalid.\n",
+ (unsigned int)newpos);
+ newpos = -EINVAL;
+ goto clean_up;
+ }
+
+ filp->f_pos = newpos;
+
+clean_up:
+ mutex_unlock(&(data->file_mutex));
+ return newpos;
+}
+
+/*
+ * rmidev_read: - use to read data from RMI stream
+ *
+ * @filp: file structure for read
+ * @buf: user-level buffer pointer
+ *
+ * @count: number of byte read
+ * @f_pos: offset (starting register address)
+ *
+ * @return number of bytes read into user buffer (buf) if succeeds
+ * negative number if error occurs.
+ */
+static ssize_t rmidev_read(struct file *filp, char __user *buf,
+ size_t count, loff_t *f_pos)
+{
+ struct rmidev_data *data = filp->private_data;
+ ssize_t retval = 0;
+ unsigned char tmpbuf[count+1];
+
+ /* limit offset to REG_ADDR_LIMIT-1 */
+ if (count > (REG_ADDR_LIMIT - *f_pos))
+ count = REG_ADDR_LIMIT - *f_pos;
+
+ if (count == 0)
+ return 0;
+
+ if (IS_ERR(data)) {
+ pr_err("%s: pointer of char device is invalid", __func__);
+ return -EBADF;
+ }
+
+ mutex_lock(&(data->file_mutex));
+
+ retval = rmi_read_block(data->rmi_dev, *f_pos, tmpbuf, count);
+
+ if (retval < 0)
+ goto clean_up;
+
+ if (copy_to_user(buf, tmpbuf, count))
+ retval = -EFAULT;
+ else
+ *f_pos += retval;
+
+clean_up:
+
+
[RFC PATCH 1/17] input: RMI4 public header file and documentation.
Signed-off-by: Christopher Heiny
Cc: Dmitry Torokhov
Cc: Linus Walleij
Cc: Naveen Kumar Gaddipati
Cc: Joeri de Gram
Acked-by: Jean Delvare
---
Documentation/input/rmi4.txt | 25 ++
Documentation/input/rmidev.txt | 144 +
Documentation/input/rmisysfs.txt | 200
include/linux/rmi.h | 652 ++
4 files changed, 1021 insertions(+), 0 deletions(-)
diff --git a/Documentation/input/rmi4.txt b/Documentation/input/rmi4.txt
new file mode 100644
index 000..4e033ff
--- /dev/null
+++ b/Documentation/input/rmi4.txt
@@ -0,0 +1,25 @@
+RMI4 Touchscreen Driver
+===
+
+TBD
+
+Firmware Update Function
+
+
+The RMI4 driver uses the kernel's request_firmware() feature to obtain
+firmware for the touch sensor. The firmware is expected to live in
+the file firmware/rmi4/.img, where is the Product ID
+found in the F01 query registers (F01_RMI_QUERY11 through F01_RMI_QUERY20).
+
+To prepare Synaptics provided .img file for reflashing, convert it to .ihex
+format using the following command:
+
+objcopy -I binary -O ihex .img
firmware/rmi4/.img.ihex
+
+Then make sure to add the image file name to the CONFIG_RMI4_FWLIB entry in
+firmware/Makefile. If you don't do this, the image file won't be included, and
+the firmware loader class will delay for 60 seconds waiting for a non-existent
+userspace response to the firmware load request.
+
+Firmware updates for multichip solutions (aka LTS) are not supported.
+
diff --git a/Documentation/input/rmidev.txt b/Documentation/input/rmidev.txt
new file mode 100644
index 000..73473ee
--- /dev/null
+++ b/Documentation/input/rmidev.txt
@@ -0,0 +1,144 @@
+RMI4 devices are typically handled by kernel drivers attached to devices on
+/sys/bus/rmi. However, user space programs can access the RMI4 devices
+through a /dev interface.
+
+Each registered RMI4 device is assigned a number, starting from 0. The rmidev
+module (if present and loaded) creates a corresponding /dev/rmiX device. This
+device is a flat binary character file that allows you to read, write, and seek
+within the register space of the corresponding RMI4 device.
+
+Opening the rmidev file is done just like opening any other file. For example,
+in C you might do the following to open the device file for the first RMI4
+device:
+int file;
+
+file = open("/dev/rmi0", O_RDWR);
+if (file < 0) {
+/* ERROR HANDLING; you can check errno to see what went wrong */
+exit(1);
+}
+
+Once the file is open, you can use read() and write() to access registers in
+the RMI4 register map. Use lseek() to specify the address at which the
+read() or write() operation will begin.
+
+
+NOTES ON ADDRESSING
+---
+
+The RMI4 register space is 16 bits wide, supporting 65536 available 8-bit
+registers. This means the range of valid positions within the file is 0
+through 65535 (0x).
+
+Attempting to lseek() to an address of 65536 or higher will return EINVAL.
+read() and write() operations that begin at 65536 or higher will return EINVAL.
+The result of read() and write() operations that begine at 65535 or below, and
+then extend beyond that boundary are undefined.
+
+Although the RMI4 register space supports 65536 registers, not all registers
+are defined or mapped on all products. Undefined or unmapped registers will
+usually return zero, but you should not rely on this behavior. The register
+map for a given device may contain 'holes' of unimplemented registers.
+
+If you're not sure what the register map for a given RMI4 device looks like,
+you can use the self describing features of RMI4 to determine the register
+map (this is what the RMI4 touchscreen driver does), or consult the product
+spec and documentation for your product.
+
+
+BUFFERED REGISTERS
+--
+
+The RMI4 specification also defines certain special registers, sometimes
+referred to as "buffered registers". Buffered registers allow large amounts
+of data to be read or written at a single address in a single read or write
+operation. Reads from (or writes to) buffered registers DO NOT increment the
+RMI4 device's internal register pointer. When reading/writing a buffered
+register, you MUST follow these steps:
+(1) lseek() to the buffered register's address
+(2) read/write all data in a single read() or write() call
+(3) lseek() to the address of the next register you wish to read/write
+
+The result of a read or write that extends across a buffered register is
+undefined. It probably won't do what you expect.
+
+The result of trying to use multiple read() or write() calls to access the
+data in a buffered register is undefined. It most certainly won't do what
+you expect.
+
+The result of failing to lseek() after reading or writing a buffered register
+is undefined. It probably won't do what you expect.
+
+For more information on buffered registers, please
[RFC PATCH 7/17] input: RMI4 F01 device control
Signed-off-by: Christopher Heiny
Cc: Dmitry Torokhov
Cc: Linus Walleij
Cc: Naveen Kumar Gaddipati
Cc: Joeri de Gram
Acked-by: Jean Delvare
---
drivers/input/rmi4/rmi_f01.c | 1331 ++
drivers/input/rmi4/rmi_f01.h | 88 +++
2 files changed, 1419 insertions(+), 0 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f01.c b/drivers/input/rmi4/rmi_f01.c
new file mode 100644
index 000..312ad13
--- /dev/null
+++ b/drivers/input/rmi4/rmi_f01.c
@@ -0,0 +1,1331 @@
+/*
+ * Copyright (c) 2011-2012 Synaptics Incorporated
+ * Copyright (c) 2011 Unixphere
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include
+#include
+#include
+#include "rmi_driver.h"
+#include "rmi_f01.h"
+
+union f01_device_commands {
+ struct {
+ u8 reset:1;
+ u8 reserved:1;
+ };
+ u8 reg;
+};
+
+struct f01_device_control {
+ union f01_device_control_0 ctrl0;
+ u8 *interrupt_enable;
+ u8 doze_interval;
+ u8 wakeup_threshold;
+ u8 doze_holdoff;
+};
+
+union f01_query_42 {
+ struct {
+ u8 has_ds4_queries:1;
+ u8 has_multi_phy:1;
+ u8 has_guest:1;
+ u8 reserved:5;
+ };
+ u8 regs[1];
+};
+
+union f01_ds4_queries {
+ struct {
+ u8 length:4;
+ u8 reserved_1:4;
+
+ u8 has_package_id_query:1;
+ u8 has_packrat_query:1;
+ u8 has_reset_query:1;
+ u8 has_maskrev_query:1;
+ u8 reserved_2:4;
+
+ u8 has_i2c_control:1;
+ u8 has_spi_control:1;
+ u8 has_attn_control:1;
+ u8 reserved_3:5;
+
+ u8 reset_enabled:1;
+ u8 reset_polarity:1;
+ u8 pullup_enabled:1;
+ u8 reserved_4:1;
+ u8 reset_pin_number:4;
+ };
+ u8 regs[4];
+};
+
+struct f01_data {
+ struct f01_device_control device_control;
+ union f01_basic_queries basic_queries;
+ union f01_device_status device_status;
+ u8 product_id[RMI_PRODUCT_ID_LENGTH+1];
+
+ u16 interrupt_enable_addr;
+ u16 doze_interval_addr;
+ u16 wakeup_threshold_addr;
+ u16 doze_holdoff_addr;
+
+ int irq_count;
+ int num_of_irq_regs;
+
+#ifdef CONFIG_PM
+ bool suspended;
+ bool old_nosleep;
+#endif
+};
+
+
+static ssize_t rmi_fn_01_productinfo_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf);
+
+static ssize_t rmi_fn_01_productid_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf);
+
+static ssize_t rmi_fn_01_manufacturer_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf);
+
+static ssize_t rmi_fn_01_datecode_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf);
+
+static ssize_t rmi_fn_01_reportrate_show(struct device *dev,
+struct device_attribute *attr,
+char *buf);
+
+static ssize_t rmi_fn_01_reportrate_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count);
+
+static ssize_t rmi_fn_01_interrupt_enable_show(struct device *dev,
+struct device_attribute *attr,
+char *buf);
+
+static ssize_t rmi_fn_01_interrupt_enable_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count);
+
+static ssize_t rmi_fn_01_doze_interval_show(struct device *dev,
+struct device_attribute *attr,
+char *buf);
+
+static ssize_t rmi_fn_01_doze_interval_store(struct device *dev,
+ struct device_attribute
[RFC PATCH 3/17] input: RMI4 physical layer drivers for I2C and SPI
Signed-off-by: Christopher Heiny
Cc: Dmitry Torokhov
Cc: Linus Walleij
Cc: Naveen Kumar Gaddipati
Cc: Joeri de Gram
Acked-by: Jean Delvare
---
drivers/input/rmi4/rmi_i2c.c | 452 +
drivers/input/rmi4/rmi_spi.c | 911 ++
2 files changed, 1363 insertions(+), 0 deletions(-)
diff --git a/drivers/input/rmi4/rmi_i2c.c b/drivers/input/rmi4/rmi_i2c.c
new file mode 100644
index 000..1da8d96
--- /dev/null
+++ b/drivers/input/rmi4/rmi_i2c.c
@@ -0,0 +1,452 @@
+/*
+ * Copyright (c) 2011, 2012 Synaptics Incorporated
+ * Copyright (c) 2011 Unixphere
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#define COMMS_DEBUG 0
+
+#define IRQ_DEBUG 0
+
+#if COMMS_DEBUG || IRQ_DEBUG
+#define DEBUG
+#endif
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "rmi_driver.h"
+
+#define RMI_PAGE_SELECT_REGISTER 0xff
+#define RMI_I2C_PAGE(addr) (((addr) >> 8) & 0xff)
+
+static char *phys_proto_name = "i2c";
+
+struct rmi_i2c_data {
+ struct mutex page_mutex;
+ int page;
+ int enabled;
+ int irq;
+ int irq_flags;
+ struct rmi_phys_device *phys;
+};
+
+static irqreturn_t rmi_i2c_irq_thread(int irq, void *p)
+{
+ struct rmi_phys_device *phys = p;
+ struct rmi_device *rmi_dev = phys->rmi_dev;
+ struct rmi_driver *driver = rmi_dev->driver;
+ struct rmi_device_platform_data *pdata = phys->dev->platform_data;
+
+#if IRQ_DEBUG
+ dev_dbg(phys->dev, "ATTN gpio, value: %d.\n",
+ gpio_get_value(pdata->attn_gpio));
+#endif
+ if (gpio_get_value(pdata->attn_gpio) == pdata->attn_polarity) {
+ phys->info.attn_count++;
+ if (driver && driver->irq_handler && rmi_dev)
+ driver->irq_handler(rmi_dev, irq);
+ }
+
+ return IRQ_HANDLED;
+}
+
+/*
+ * rmi_set_page - Set RMI page
+ * @phys: The pointer to the rmi_phys_device struct
+ * @page: The new page address.
+ *
+ * RMI devices have 16-bit addressing, but some of the physical
+ * implementations (like SMBus) only have 8-bit addressing. So RMI implements
+ * a page address at 0xff of every page so we can reliable page addresses
+ * every 256 registers.
+ *
+ * The page_mutex lock must be held when this function is entered.
+ *
+ * Returns zero on success, non-zero on failure.
+ */
+static int rmi_set_page(struct rmi_phys_device *phys, unsigned int page)
+{
+ struct i2c_client *client = to_i2c_client(phys->dev);
+ struct rmi_i2c_data *data = phys->data;
+ char txbuf[2] = {RMI_PAGE_SELECT_REGISTER, page};
+ int retval;
+
+#if COMMS_DEBUG
+ dev_dbg(>dev, "RMI4 I2C writes 3 bytes: %02x %02x\n",
+ txbuf[0], txbuf[1]);
+#endif
+ phys->info.tx_count++;
+ phys->info.tx_bytes += sizeof(txbuf);
+ retval = i2c_master_send(client, txbuf, sizeof(txbuf));
+ if (retval != sizeof(txbuf)) {
+ phys->info.tx_errs++;
+ dev_err(>dev,
+ "%s: set page failed: %d.", __func__, retval);
+ return (retval < 0) ? retval : -EIO;
+ }
+ data->page = page;
+ return 0;
+}
+
+static int rmi_i2c_write_block(struct rmi_phys_device *phys, u16 addr, u8 *buf,
+ int len)
+{
+ struct i2c_client *client = to_i2c_client(phys->dev);
+ struct rmi_i2c_data *data = phys->data;
+ u8 txbuf[len + 1];
+ int retval;
+#ifCOMMS_DEBUG
+ char debug_buf[len*3 + 1];
+ int i, n;
+#endif
+
+ txbuf[0] = addr & 0xff;
+ memcpy(txbuf + 1, buf, len);
+
+ mutex_lock(>page_mutex);
+
+ if (RMI_I2C_PAGE(addr) != data->page) {
+ retval = rmi_set_page(phys, RMI_I2C_PAGE(addr));
+ if (retval < 0)
+ goto exit;
+ }
+
+#if COMMS_DEBUG
+ n = 0;
+ for (i = 0; i < len; i++)
+ n = snprintf(debug_buf+n, 4, "%02x ", buf[i]);
+ dev_dbg(>dev, "RMI4 I2C writes %d bytes at %#06x: %s\n",
+ len, addr, debug_buf);
+#endif
+
+ phys->info.tx_count++;
+ phys->info.tx_bytes += sizeof(txbuf);
+ retval = i2c_master_send(client, txbuf, sizeof(txbuf));
+ if (retval < 0)
+
[RFC PATCH 13/17] input: RMI4 F21 Force sensing
Signed-off-by: Christopher Heiny
Cc: Dmitry Torokhov
Cc: Linus Walleij
Cc: Naveen Kumar Gaddipati
Cc: Joeri de Gram
Acked-by: Jean Delvare
---
drivers/input/rmi4/rmi_f21.c | 832 ++
1 files changed, 832 insertions(+), 0 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f21.c b/drivers/input/rmi4/rmi_f21.c
new file mode 100644
index 000..2e37c75
--- /dev/null
+++ b/drivers/input/rmi4/rmi_f21.c
@@ -0,0 +1,832 @@
+/*
+ * Copyright (c) 2012-2012 Synaptics Incorporated
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#define FUNCTION_DATA rmi_fn_21_data
+#define FNUM 21
+
+
+#include
+#include
+#include
+#include "rmi_driver.h"
+
+union f21_2df_query {
+ struct {
+ /* Query 0 */
+ u8 max_force_sensor_count:3;
+ u8 f21_2df_query0_b3__6:4;
+ u8 has_high_resolution:1;
+ } __attribute__((__packed__));
+ struct {
+ u8 regs[1];
+ u16 address;
+ } __attribute__((__packed__));
+};
+
+union f21_2df_control_0__3 {
+ struct {
+ /* Control 0 */
+ u8 reporting_mode:3;
+ u8 no_rezero:1;
+ u8 ctl0_reserved:4;
+
+ /* Control 1 */
+ u8 force_click_threshold:8;
+
+ /* Control 2 */
+ u8 int_en_force_0:1;
+ u8 int_en_force_1:1;
+ u8 int_en_force_2:1;
+ u8 int_en_force_3:1;
+ u8 int_en_force_4:1;
+ u8 int_en_force_5:1;
+ u8 int_en_force_6:1;
+ u8 int_en_click:1;
+
+ /* Control 3 */
+ u8 force_interrupt_threshold:8;
+ } __attribute__((__packed__));
+ struct {
+ u8 regs[4];
+ u16 address;
+ } __attribute__((__packed__));
+};
+
+struct f21_2df_control_4n {
+ /*Control 4.* */
+ u8 one_newton_linear_calibration:7;
+ u8 use_cfg_cal:1;
+} __attribute__((__packed__));
+
+struct f21_2df_control_4 {
+ struct f21_2df_control_4n *regs;
+ u16 address;
+ u8 length;
+} __attribute__((__packed__));
+
+struct f21_2df_control_5n {
+ /* Control 5 */
+ u8 one_newton_nonlinear_calibration;
+};
+
+struct f21_2df_control_5 {
+ struct f21_2df_control_5n *regs;
+ u16 address;
+ u8 length;
+};
+
+struct f21_2df_control_6n {
+ /*Control 6.* */
+ u8 x_location;
+};
+
+struct f21_2df_control_6 {
+ struct f21_2df_control_6n *regs;
+ u16 address;
+ u8 length;
+};
+
+struct f21_2df_control_7n {
+ /*Control 7.* */
+ u8 y_location;
+};
+
+struct f21_2df_control_7 {
+ struct f21_2df_control_7n *regs;
+ u16 address;
+ u8 length;
+};
+
+struct f21_2df_control_8n {
+ /*Control 8.* */
+ u8 transmitter_force_sensor;
+};
+
+struct f21_2df_control_8 {
+ struct f21_2df_control_8n *regs;
+ u16 address;
+ u8 length;
+};
+
+struct f21_2df_control_9n {
+ /*Control 9.* */
+ u8 receiver_force_sensor;
+};
+
+struct f21_2df_control_9 {
+ struct f21_2df_control_9n *regs;
+ u16 address;
+ u8 length;
+};
+
+
+#define RMI_F21_NUM_CTRL_REGS 8
+struct f21_2df_control {
+ /* Control 0-3 */
+ union f21_2df_control_0__3 *reg_0__3;
+
+ /* Control 4 */
+ struct f21_2df_control_4 *reg_4;
+
+ /* Control 5 */
+ struct f21_2df_control_5 *reg_5;
+
+ /* Control 6 */
+ struct f21_2df_control_6 *reg_6;
+
+ /* Control 7 */
+ struct f21_2df_control_7 *reg_7;
+
+ /* Control 8 */
+ struct f21_2df_control_8 *reg_8;
+
+ /* Control 9 */
+ struct f21_2df_control_9 *reg_9;
+};
+
+union f21_2df_data_2 {
+ struct {
+ /* Data 2 */
+ u8 force_click:1;
+ u8 f21_2df_control0_b2__7:7;
+ } __attribute__((__packed__));
+ struct {
+ u8 regs[1];
+ u16 address;
+ } __attribute__((__packed__));
+};
+
+struct f21_2df_data {
+ /* Data 0 */
+ struct {
+ u8 *force_hi_lo;
+ u16
[RFC PATCH 11/17] input: RMI4 F19 capacitive buttons
Signed-off-by: Christopher Heiny
Cc: Dmitry Torokhov
Cc: Linus Walleij
Cc: Naveen Kumar Gaddipati
Cc: Joeri de Gram
Acked-by: Jean Delvare
---
drivers/input/rmi4/rmi_f19.c | 869 ++
1 files changed, 869 insertions(+), 0 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f19.c b/drivers/input/rmi4/rmi_f19.c
new file mode 100644
index 000..9e9ea93
--- /dev/null
+++ b/drivers/input/rmi4/rmi_f19.c
@@ -0,0 +1,869 @@
+/*
+ * Copyright (c) 2012 Synaptics Incorporated
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#define FUNCTION_DATA f19_data
+#define FNUM 19
+
+#include
+#include
+#include
+#include
+#include "rmi_driver.h"
+
+#define QUERY_BASE_INDEX 1
+#define MAX_LEN 256
+#define MAX_BUFFER_LEN 80
+
+#define SENSOR_MAP_MIN 0
+#define SENSOR_MAP_MAX 127
+#define SENSITIVITY_ADJ_MIN0
+#define SENSITIVITY_ADJ_MAX31
+#define HYSTERESIS_THRESHOLD_MIN 0
+#define HYSTERESIS_THRESHOLD_MAX 15
+
+union f19_0d_query {
+ struct {
+ u8 configurable:1;
+ u8 has_sensitivity_adjust:1;
+ u8 has_hysteresis_threshold:1;
+ u8 reserved_1:5;
+
+ u8 button_count:5;
+ u8 reserved_2:3;
+ } __attribute__((__packed__));
+ struct {
+ u8 regs[2];
+ u16 address;
+ } __attribute__((__packed__));
+};
+
+union f19_0d_control_0 {
+ struct {
+ u8 button_usage:2;
+ u8 filter_mode:2;
+ } __attribute__((__packed__));
+ struct {
+ u8 regs[1];
+ u16 address;
+ } __attribute__((__packed__));
+};
+/* rewrite control regs */
+struct f19_0d_control_1n {
+ u8 int_enabled_button;
+};
+
+struct f19_0d_control_1 {
+ struct f19_0d_control_1n *regs;
+ u16 address;
+ u8 length;
+} __attribute__((__packed__));
+
+struct f19_0d_control_2n {
+ u8 single_button;
+};
+
+struct f19_0d_control_2 {
+ struct f19_0d_control_2n *regs;
+ u16 address;
+ u8 length;
+} __attribute__((__packed__));
+
+struct f19_0d_control_3n {
+ u8 sensor_map_button:7;
+};
+
+struct f19_0d_control_3 {
+ struct f19_0d_control_3n *regs;
+ u16 address;
+ u8 length;
+} __attribute__((__packed__));
+
+struct f19_0d_control_4n {
+ u8 sensitivity_button:7;
+};
+
+struct f19_0d_control_4 {
+ struct f19_0d_control_4n *regs;
+ u16 address;
+ u8 length;
+} __attribute__((__packed__));
+
+union f19_0d_control_5 {
+ struct {
+ u8 sensitivity_adj:5;
+ };
+ struct {
+ u8 regs[1];
+ u16 address;
+ } __attribute__((__packed__));
+};
+
+union f19_0d_control_6 {
+ struct {
+ u8 hysteresis_threshold:4;
+ };
+ struct {
+ u8 regs[1];
+ u16 address;
+ } __attribute__((__packed__));
+};
+
+struct f19_0d_control {
+ union f19_0d_control_0 *reg_0;
+ struct f19_0d_control_1 *reg_1;
+ struct f19_0d_control_2 *reg_2;
+ struct f19_0d_control_3 *reg_3;
+ struct f19_0d_control_4 *reg_4;
+ union f19_0d_control_5 *reg_5;
+ union f19_0d_control_6 *reg_6;
+};
+
+/* data specific to fn $19 that needs to be kept around */
+struct f19_data {
+ struct f19_0d_control control;
+ union f19_0d_query query;
+ u8 button_rezero;
+ unsigned char button_count;
+ unsigned char button_bitmask_size;
+ unsigned char *button_data_buffer;
+ unsigned short *button_map;
+ char input_name[MAX_LEN];
+ char input_phys[MAX_LEN];
+ struct input_dev *input;
+ struct mutex control_mutex;
+ struct mutex data_mutex;
+};
+
+
+static int rmi_f19_alloc_memory(struct rmi_function_container *fc);
+
+static void rmi_f19_free_memory(struct rmi_function_container *fc);
+
+static int rmi_f19_initialize(struct rmi_function_container *fc);
+
+static int rmi_f19_register_device(struct rmi_function_container *fc);
+
+static int rmi_f19_create_sysfs(struct rmi_function_container *fc);
+
+static int rmi_f19_config(struct rmi_function_container *fc);
+
+static int rmi_f19_reset(struct rmi_function_container *fc);
+
+/* Query sysfs files
[RFC PATCH 8/17] input: RMI4 F09 Built-In Self Test
Signed-off-by: Christopher Heiny
Cc: Dmitry Torokhov
Cc: Linus Walleij
Cc: Naveen Kumar Gaddipati
Cc: Joeri de Gram
Acked-by: Jean Delvare
---
drivers/input/rmi4/rmi_f09.c | 772 ++
1 files changed, 772 insertions(+), 0 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f09.c b/drivers/input/rmi4/rmi_f09.c
new file mode 100644
index 000..ee3058e
--- /dev/null
+++ b/drivers/input/rmi4/rmi_f09.c
@@ -0,0 +1,772 @@
+/*
+ * Copyright (c) 2011, 2012 Synaptics Incorporated
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#include
+#include
+#include
+#include
+#include "rmi_driver.h"
+
+#define QUERY_BASE_INDEX 1
+
+/* data specific to fn $09 that needs to be kept around */
+struct f09_query {
+ u8 limit_register_count;
+ union {
+ struct {
+ u8 result_register_count:3;
+ u8 reserved:3;
+ u8 internal_limits:1;
+ u8 host_test_enable:1;
+ };
+ u8 f09_bist_query1;
+ };
+};
+
+struct f09_control {
+ union {
+ struct {
+ u8 test1_limit_low:8;
+ u8 test1_limit_high:8;
+ u8 test1_limit_diff:8;
+ };
+ u8 f09_control_test1[3];
+ };
+ union {
+ struct {
+ u8 test2_limit_low:8;
+ u8 test2_limit_high:8;
+ u8 test2_limit_diff:8;
+ };
+ u8 f09_control_test2[3];
+ };
+};
+
+struct f09_data {
+ u8 test_number_control;
+ u8 overall_bist_result;
+ u8 test_result1;
+ u8 test_result2;
+ u8 transmitter_number;
+
+ union {
+ struct {
+ u8 receiver_number:6;
+ u8 limit_failure_code:2;
+ };
+ u8 f09_bist_data2;
+ };
+};
+
+struct f09_cmd {
+ union {
+ struct {
+ u8 run_bist:1;
+ };
+ u8 f09_bist_cmd0;
+ };
+};
+
+struct rmi_fn_09_data {
+ struct f09_query query;
+ struct f09_data data;
+ struct f09_cmd cmd;
+ struct f09_control control;
+ signed char status;
+};
+
+
+static ssize_t rmi_f09_status_show(struct device *dev,
+struct device_attribute *attr, char *buf);
+
+static ssize_t rmi_f09_status_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count);
+
+static ssize_t rmi_f09_limit_register_count_show(struct device *dev,
+ struct device_attribute *attr, char *buf);
+
+static ssize_t rmi_f09_host_test_enable_show(struct device *dev,
+ struct device_attribute *attr, char *buf);
+
+static ssize_t rmi_f09_host_test_enable_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count);
+
+static ssize_t rmi_f09_internal_limits_show(struct device *dev,
+ struct device_attribute *attr, char *buf);
+
+static ssize_t rmi_f09_result_register_count_show(struct device *dev,
+ struct device_attribute *attr, char *buf);
+
+static ssize_t rmi_f09_overall_bist_result_show(struct device *dev,
+ struct device_attribute *attr, char *buf);
+
+static ssize_t rmi_f09_test_number_control_show(struct device *dev,
+ struct device_attribute *attr, char *buf);
+
+static ssize_t rmi_f09_test_number_control_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count);
+
+static ssize_t rmi_f09_run_bist_show(struct device *dev,
+ struct device_attribute *attr, char *buf);
+
+static ssize_t rmi_f09_run_bist_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count);
+
[RFC PATCH 6/17] input: RMI4 firmware update
Signed-off-by: Christopher Heiny
Cc: Dmitry Torokhov
Cc: Linus Walleij
Cc: Naveen Kumar Gaddipati
Cc: Joeri de Gram
Acked-by: Jean Delvare
---
drivers/input/rmi4/rmi_fw_update.c | 724
1 files changed, 724 insertions(+), 0 deletions(-)
diff --git a/drivers/input/rmi4/rmi_fw_update.c
b/drivers/input/rmi4/rmi_fw_update.c
new file mode 100644
index 000..7f6c315
--- /dev/null
+++ b/drivers/input/rmi4/rmi_fw_update.c
@@ -0,0 +1,724 @@
+/*
+ * Copyright (c) 2012 Synaptics Incorporated
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#define DEBUG
+
+#define RIM_HACK 1
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "rmi_driver.h"
+#include "rmi_f01.h"
+#include "rmi_f34.h"
+
+#define HAS_BSR_MASK 0x20
+
+#define CHECKSUM_OFFSET 0
+#define BOOTLOADER_VERSION_OFFSET 0x07
+#define IMAGE_SIZE_OFFSET 0x08
+#define CONFIG_SIZE_OFFSET 0x0C
+#define PRODUCT_ID_OFFSET 0x10
+#define PRODUCT_ID_SIZE 10
+#define PRODUCT_INFO_OFFSET 0x1E
+#define PRODUCT_INFO_SIZE 2
+
+#define F01_RESET_MASK 0x01
+
+#define ENABLE_WAIT_US (300 * 1000)
+
+/** Image file V5, Option 0
+ */
+struct image_header {
+ u32 checksum;
+ unsigned int image_size;
+ unsigned int config_size;
+ unsigned char options;
+ unsigned char bootloader_version;
+ u8 product_id[RMI_PRODUCT_ID_LENGTH + 1];
+ unsigned char product_info[PRODUCT_INFO_SIZE];
+};
+
+static u32 extract_u32(const u8 *ptr)
+{
+ return (u32)ptr[0] +
+ (u32)ptr[1] * 0x100 +
+ (u32)ptr[2] * 0x1 +
+ (u32)ptr[3] * 0x100;
+}
+
+struct reflash_data {
+ struct rmi_device *rmi_dev;
+ struct pdt_entry *f01_pdt;
+ union f01_basic_queries f01_queries;
+ union f01_device_control_0 f01_controls;
+ char product_id[RMI_PRODUCT_ID_LENGTH+1];
+ struct pdt_entry *f34_pdt;
+ u8 bootloader_id[2];
+ union f34_query_regs f34_queries;
+ union f34_control_status f34_controls;
+ const u8 *firmware_data;
+ const u8 *config_data;
+};
+
+/* If this parameter is true, we will update the firmware regardless of
+ * the versioning info.
+ */
+static bool force = 1;
+module_param(force, bool, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(param, "Force reflash of RMI4 devices");
+
+/* If this parameter is not NULL, we'll use that name for the firmware image,
+ * instead of getting it from the F01 queries.
+ */
+static char *img_name;
+module_param(img_name, charp, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(param, "Name of the RMI4 firmware image");
+
+#define RMI4_IMAGE_FILE_REV1_OFFSET 30
+#define RMI4_IMAGE_FILE_REV2_OFFSET 31
+#define IMAGE_FILE_CHECKSUM_SIZE 4
+#define FIRMWARE_IMAGE_AREA_OFFSET 0x100
+
+static void extract_header(const u8 *data, int pos, struct image_header
*header)
+{
+ header->checksum = extract_u32([pos + CHECKSUM_OFFSET]);
+ header->bootloader_version = data[pos + BOOTLOADER_VERSION_OFFSET];
+ header->image_size = extract_u32([pos + IMAGE_SIZE_OFFSET]);
+ header->config_size = extract_u32([pos + CONFIG_SIZE_OFFSET]);
+ memcpy(header->product_id, [pos + PRODUCT_ID_OFFSET],
+ RMI_PRODUCT_ID_LENGTH);
+ header->product_id[PRODUCT_ID_SIZE] = 0;
+ memcpy(header->product_info, [pos + PRODUCT_INFO_OFFSET],
+ RMI_PRODUCT_ID_LENGTH);
+}
+
+static int rescan_pdt(struct reflash_data *data)
+{
+ int retval;
+ bool f01_found;
+ bool f34_found;
+ struct pdt_entry pdt_entry;
+ int i;
+ struct rmi_device *rmi_dev = data->rmi_dev;
+ struct pdt_entry *f34_pdt = data->f34_pdt;
+ struct pdt_entry *f01_pdt = data->f01_pdt;
+
+ /* Per spec, once we're in reflash we only need to look at the first
+* PDT page for potentially changed F01 and F34 information.
+*/
+ for (i = PDT_START_SCAN_LOCATION; i >= PDT_END_SCAN_LOCATION;
+ i -= sizeof(pdt_entry)) {
+ retval = rmi_read_block(rmi_dev, i, (u8 *)_entry,
+ sizeof(pdt_entry));
+ if (retval != sizeof(pdt_entry)) {
+ dev_err(_dev->dev,
+ "Read PDT entry at %#06x failed: %d.\n",
+
[RFC PATCH 10/17] input: RM4 F17 Pointing sticks
Signed-off-by: Christopher Heiny
Cc: Dmitry Torokhov
Cc: Linus Walleij
Cc: Naveen Kumar Gaddipati
Cc: Joeri de Gram
Acked-by: Jean Delvare
---
drivers/input/rmi4/rmi_f17.c | 713 ++
1 files changed, 713 insertions(+), 0 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f17.c b/drivers/input/rmi4/rmi_f17.c
new file mode 100644
index 000..006a716
--- /dev/null
+++ b/drivers/input/rmi4/rmi_f17.c
@@ -0,0 +1,713 @@
+/*
+ * Copyright (c) 2012 Synaptics Incorporated
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#include
+#include
+#include
+#include
+#include "rmi_driver.h"
+
+#define QUERY_BASE_INDEX 1
+#define MAX_NAME_LENGTH 256
+
+union f17_device_query {
+ struct {
+ u8 number_of_sticks:3;
+ };
+ u8 regs[1];
+};
+
+#define F17_MANUFACTURER_SYNAPTICS 0
+#define F17_MANUFACTURER_NMB 1
+#define F17_MANUFACTURER_ALPS 2
+
+struct f17_stick_query {
+ union {
+ struct {
+ u8 manufacturer:4;
+ u8 resistive:1;
+ u8 ballistics:1;
+ u8 reserved1:2;
+ u8 has_relative:1;
+ u8 has_absolute:1;
+ u8 has_gestures:1;
+ u8 has_dribble:1;
+ u8 reserved2:4;
+ };
+ u8 regs[2];
+ } general;
+
+ union {
+ struct {
+ u8 has_single_tap:1;
+ u8 has_tap_and_hold:1;
+ u8 has_double_tap:1;
+ u8 has_early_tap:1;
+ u8 has_press:1;
+ };
+ u8 regs[1];
+ } gestures;
+};
+
+union f17_device_controls {
+ struct {
+ u8 reporting_mode:3;
+ u8 dribble:1;
+ };
+ u8 regs[1];
+};
+
+struct f17_stick_controls {
+ union {
+ struct {
+ u8 z_force_threshold;
+ u8 radial_force_threshold;
+ };
+ u8 regs[3];
+ } general;
+
+ union {
+ struct {
+ u8 motion_sensitivity:4;
+ u8 antijitter:1;
+ };
+ u8 regs[1];
+ } relative;
+
+ union {
+ struct {
+ u8 single_tap:1;
+ u8 tap_and_hold:1;
+
+ u8 double_tap:1;
+ u8 early_tap:1;
+ u8 press:1;
+ };
+ u8 regs[1];
+ } enable;
+
+ u8 maximum_tap_time;
+ u8 minimum_press_time;
+ u8 maximum_radial_force;
+};
+
+
+union f17_device_commands {
+ struct {
+ u8 rezero:1;
+ };
+ u8 regs[1];
+};
+
+struct f17_stick_data {
+ union {
+ struct {
+ u8 x_force_high:8;
+ u8 y_force_high:8;
+ u8 y_force_low:4;
+ u8 x_force_low:4;
+ u8 z_force:8;
+ } __attribute__((__packed__));
+ struct {
+ u8 regs[4];
+ u16 address;
+ };
+ } abs;
+ union {
+ struct {
+ s8 x_delta:8;
+ s8 y_delta:8;
+ } __attribute__((__packed__));
+ struct {
+ u8 regs[2];
+ u16 address;
+ };
+ } rel;
+ union {
+ struct {
+ u8 single_tap:1;
+ u8 tap_and_hold:1;
+ u8 double_tap:1;
+ u8 early_tap:1;
+ u8 press:1;
+ u8 reserved:3;
+ } __attribute__((__packed__));
+ struct {
+ u8 regs[1];
+ u16 address;
+ };
+ } gestures;
+};
+
+
+/* data specific to f17 that needs to be kept around */
+
+struct rmi_f17_stick_data {
+ struct f17_stick_query query;
+ struct f17_stick_controls controls;
+ struct f17_stick_data data;
+
+ u16
[RFC PATCH 4/17] input: RMI4 configs and makefiles
Signed-off-by: Christopher Heiny Cc: Dmitry Torokhov Cc: Linus Walleij Cc: Naveen Kumar Gaddipati Cc: Joeri de Gram Acked-by: Jean Delvare --- drivers/input/Kconfig |2 + drivers/input/Makefile |4 +- drivers/input/rmi4/Kconfig | 262 +++ drivers/input/rmi4/Makefile | 18 +++ 4 files changed, 284 insertions(+), 2 deletions(-) diff --git a/drivers/input/Kconfig b/drivers/input/Kconfig index 1903c0f..0cdd8a5 100644 --- a/drivers/input/Kconfig +++ b/drivers/input/Kconfig @@ -185,6 +185,8 @@ source "drivers/input/touchscreen/Kconfig" source "drivers/input/misc/Kconfig" +source "drivers/input/rmi4/Kconfig" + endif menu "Hardware I/O ports" diff --git a/drivers/input/Makefile b/drivers/input/Makefile index 09614ce..cfb383e 100644 --- a/drivers/input/Makefile +++ b/drivers/input/Makefile @@ -23,6 +23,6 @@ obj-$(CONFIG_INPUT_TABLET)+= tablet/ obj-$(CONFIG_INPUT_TOUCHSCREEN)+= touchscreen/ obj-$(CONFIG_INPUT_MISC) += misc/ -obj-$(CONFIG_INPUT_APMPOWER) += apm-power.o +obj-$(CONFIG_INPUT_RMI4) += rmi4/ -obj-$(CONFIG_XEN_KBDDEV_FRONTEND) += xen-kbdfront.o +obj-$(CONFIG_INPUT_APMPOWER) += apm-power.o diff --git a/drivers/input/rmi4/Kconfig b/drivers/input/rmi4/Kconfig new file mode 100644 index 000..3cedf8b --- /dev/null +++ b/drivers/input/rmi4/Kconfig @@ -0,0 +1,262 @@ +# +# RMI4 configuration +# +config RMI4_BUS + bool "Synaptics RMI4 bus support" + help + Say Y here if you want to support the Synaptics RMI4 bus. This is + required for all RMI4 device support. + + If unsure, say Y. + + This feature is not currently available as a loadable module. + +config RMI4_DEBUG + bool "RMI4 Debugging" + depends on RMI4_BUS + help + Say Y here to enable debug feature in the RMI4 driver. + + Note that the RMI4 driver debug features can generate a lot of + output (potentially clogging up your dmesg output) and generally + slow down driver operation. It's recommended to enable them only + if you are actively developing/debugging RMI4 features. + + If unsure, say N. + +config RMI4_SPECIAL_EARLYSUSPEND + bool "Synaptics RMI4 special early suspend" + depends on RMI4_BUS && HAS_EARLYSUSPEND + help + Say Y here to enable special suspend handling in the RMI4 driver. + + This feature causes the RMI4 sensors to be placed in full suspend + state during the early suspend process. The standard early suspend + and late resume handlers will be replaced by the suspend and resume + handling routines. The result will be a small savings in power + consumption, at the expense of decreased UI responsiveness at late + resume. Enable this feature only if you have extremely limited + power resources in your system. + + If unsure, say N. + +config RMI4_FWLIB + bool "RMI4 Firmware Update" + depends on RMI4_BUS + help + Say Y here to enable in-kernel firmware update capability. + + The RMI4 driver will check for firmware updates during the device + initialization process, and apply the updates if appropriate. + + This feature is not available as a loadable module. + + +config RMI4_I2C + bool "RMI4 I2C Support" + depends on RMI4_BUS && I2C + help + Say Y here if you want to support RMI4 devices connected to an I2C + bus. + + If unsure, say Y. + + This feature is not currently available as a loadable module. + +config RMI4_SPI + bool "RMI4 SPI Support" + depends on RMI4_BUS && SPI + help + Say Y here if you want to support RMI4 devices connected to an SPI + bus. + + If unsure, say Y. + + This feature is not currently available as a loadable module. + +config RMI4_SMB + bool "RMI4 SMB Support" + depends on RMI4_BUS + help + Say Y here if you want to support RMI4 devices connected to an SMB + bus. + + If unsure, say Y. + + This feature is not currently available as a loadable module. + +config RMI4_GENERIC + bool "RMI4 Generic driver" + depends on RMI4_BUS + help + Say Y here if you want to support generic RMI4 devices. + + This is pretty much required if you want to do anything useful with + your RMI device. + + This feature is not currently available as a loadable module. + + +config RMI4_F1A + tristate "RMI4 Function 1A (capacitive button sensor)" + depends on RMI4_BUS && RMI4_GENERIC + help + Say Y here if you want to add support for RMI4 function 1A. + + Function 1A provides self testing for touchscreens and touchpads. + + To compile this driver as a module, choose M here: the + module will be called rmi-f1a. + +config RMI4_F09 +
[RFC PATCH 00/11] input: Synaptics RMI4 Touchscreen Driver
This patch implements a driver supporting Synaptics ClearPad and other touchscreen sensors that use the RMI4 protocol, as defined here: http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4%20Intrfacing%20Guide.pdf as well as successor documents that haven't made their way through to publication yet. This code supersedes the patch submitted on 2011-12-21. We believe that all outstanding issues arising from the previous submissions have been addressed, except certain issues relating to the use of device_type and the binding of the individual function drivers (see below). This patch is against the v2.6.38 tag of Linus' kernel tree, commit 521cb40b0c44418a4fd36dc633f575813d59a43d. This will be our last patch against such an old kernel version, future patches will be against 3.x kernels. Included in this patch are: - full support for an RMI virtual bus as a standard kernel bus - physical layer implementations for I2C and SPI - function implementations for the following RMI4 functions: * F01 device control * F09 self test (aka BIST) * F11 multifinger pointing * F17 pointing sticks * F19 capacitive buttons * F1A simple capacitive buttons * F21 force sensing * F30 GPIO and LED controls * F34 device reflash * F41 active pen pointing * F54 analog data reporting - character device access to the RMI4 register map via rmidev - firmware reflash using the request_firmware mechanism The driver supports a system having one or more RMI sensors attached to it. Most devices have just a single touch sensor, but some have more than one. An example is the Fuse concept phone, which has 4 RMI sensors in it. Each sensor is presented as a device on the RMI logical bus (/sys/bus/rmi). Devices are named/numbered in the order they are discovered on the bus, starting with /sys/bus/rmi/devices/sensor00 for the first once, .../sensor01 for the second one, and so on. Individual RMI functions are presented as child devices of the sensor device. For example, sensor00/fn01, sensor00/fn11, and so on. Control of an RMI function's operating parameters is implemented via sysfs. For diagnostic purposes, the rmidev interface is provided. This implements a character device (/dev/rmi0, and so on) that provides flat file access to the RMI4 register map. For more information, see the file Documentation/input/rmidev.txt. Note regarding device_type and functional driver matching. Feedback on our patch submission from 2011-12 requested that we use device_type to help match drivers that worked directly with the sensor (such as rmi_dev.c) and drivers that work with individual functions (such as rmi_f11.c). We spent some effort on this request, but in the meantime the original customer requirements that led to the differentiation between the two types of driver no longer exist. As a result, we have rolled back that work, and plan to merge the rmi_dev functionality into the core of the driver, eliminating the need to support two device_types and their drivers. This will be included in our next patch submission, along with changes to how function drivers are matched functions. We considered postponing this patch until that was done, but it's been a very long time since the last one, and we wanted to make the other work available. Due to the large amount of code, we've broken this patch into 17 parts, as follows: 01 - public header files and documentation 02 - core sensor and bus implementation 03 - physical layer drivers 04 - Kconfigs and Makefiles 05 - rmidev 06 - firmware update 07..17 - drivers for individual RMI functions Comments and other feedback on this driver are welcomed. Christopher Heiny and the Synaptics RMI4 driver team Signed-off-by: Christopher Heiny Cc: Jean Delvare Cc: Linus Walleij Cc: Naveen Kumar Gaddipati Cc: Joeri de Gram --- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] [PATCH 6/7] drm/i915: Disable FDI RX before FDI TX
"Lespiau, Damien" writes: > I can't see anything in the docs about an order requirement for those. Right, the docs don't say anything, which is a bit disconcerting. > Not sure why the other way does not make sense. Somehow disabling TX > before RX makes some sense to me (TX enabled without a ready RX looks > weird?, no data should flow as the pipe is shutdown at that point > anyway). Maybe it just does not matter? And here I figured disabling RX before TX made more sense -- otherwise the receiver wouldn't be seeing anything. In other areas of the driver, we're careful to disable receivers before senders (disable CRTC before PLL, etc). > Another detail is that disabling the PLLs seem to have an order in the > disabling sequence, TX, then RX. > > I. Disable CPU FDI Transmitter PLL > II. Disable PCH FDI Receiver PLL That ordering doesn't matter as the FDI receiver and transmitter are both disabled by that point, so they aren't talking at all. -- keith.pack...@intel.com pgpju5BT6Xibx.pgp Description: PGP signature
Re: [PATCH 3/8] ext3: remove lock/unlock super
On Fri, Aug 17, 2012 at 08:47:04AM +0200, Marco Stornelli wrote:
> Great. I'll remove the calls for ext3/ext4 when I'll submit the
> second version of the patch.
FYI, I have the following patch my ext4 tree, so I could do more
intensive testing. I'll let folks know if anything goes horribly
wrong, but I'm pretty sure this should be safe.
- Ted
>From 81f74e743344217487792e4190f9478963d1bb21 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o
Date: Fri, 17 Aug 2012 19:00:34 -0400
Subject: [PATCH] ext4: drop lock_super()/unlock_super()
We don't need lock_super()/unlock_super() any more, since the places
where it is used, we are protected by the s_umount r/w semaphore.
Signed-off-by: "Theodore Ts'o"
Cc: Marco Stornelli
---
fs/ext4/super.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 3ab798d..bae4124 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -861,7 +861,6 @@ static void ext4_put_super(struct super_block *sb)
flush_workqueue(sbi->dio_unwritten_wq);
destroy_workqueue(sbi->dio_unwritten_wq);
- lock_super(sb);
if (sbi->s_journal) {
err = jbd2_journal_destroy(sbi->s_journal);
sbi->s_journal = NULL;
@@ -928,7 +927,6 @@ static void ext4_put_super(struct super_block *sb)
* Now that we are completely done shutting down the
* superblock, we need to actually destroy the kobject.
*/
- unlock_super(sb);
kobject_put(>s_kobj);
wait_for_completion(>s_kobj_unregister);
if (sbi->s_chksum_driver)
@@ -4535,11 +4533,9 @@ static int ext4_unfreeze(struct super_block *sb)
if (sb->s_flags & MS_RDONLY)
return 0;
- lock_super(sb);
/* Reset the needs_recovery flag before the fs is unlocked. */
EXT4_SET_INCOMPAT_FEATURE(sb, EXT4_FEATURE_INCOMPAT_RECOVER);
ext4_commit_super(sb, 1);
- unlock_super(sb);
return 0;
}
@@ -4575,7 +4571,6 @@ static int ext4_remount(struct super_block *sb, int
*flags, char *data)
char *orig_data = kstrdup(data, GFP_KERNEL);
/* Store the original options */
- lock_super(sb);
old_sb_flags = sb->s_flags;
old_opts.s_mount_opt = sbi->s_mount_opt;
old_opts.s_mount_opt2 = sbi->s_mount_opt2;
@@ -4717,7 +4712,6 @@ static int ext4_remount(struct super_block *sb, int
*flags, char *data)
if (sbi->s_journal == NULL)
ext4_commit_super(sb, 1);
- unlock_super(sb);
#ifdef CONFIG_QUOTA
/* Release old quota file names */
for (i = 0; i < MAXQUOTAS; i++)
@@ -4730,10 +4724,8 @@ static int ext4_remount(struct super_block *sb, int
*flags, char *data)
else if (EXT4_HAS_RO_COMPAT_FEATURE(sb,
EXT4_FEATURE_RO_COMPAT_QUOTA)) {
err = ext4_enable_quotas(sb);
- if (err) {
- lock_super(sb);
+ if (err)
goto restore_opts;
- }
}
}
#endif
@@ -4760,7 +4752,6 @@ restore_opts:
sbi->s_qf_names[i] = old_opts.s_qf_names[i];
}
#endif
- unlock_super(sb);
kfree(orig_data);
return err;
}
--
1.7.12.rc0.22.gcdd159b
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver
On 08/17/2012 03:55 PM, Dave Airlie wrote: > On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie wrote: >> On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap wrote: >>> On 08/17/2012 03:25 PM, Justin M. Forbes wrote: >>> for , we have verified cases on inteldrmfb, radeondrmfb, and cirrusdrmfb. This is the last message displayed before the system hangs. This seems to be hitting a large number of users in Fedora, though certainly not everyone. This started happening with the 3.5 updates, and is still an issue. It appears to be a race condition, because various things have allowed boot to continue for some users, though there is no clear work around. Has anyone else run across this? Any ideas. For more background we have the following bugs: inteldrmfb: https://bugzilla.redhat.com/show_bug.cgi?id=843826 radeondrmfb: https://bugzilla.redhat.com/show_bug.cgi?id=845745 cirrusdrmfb : https://bugzilla.redhat.com/show_bug.cgi?id=843860 It should be noted that the conflicting fb hw usage message is not new, it has been around for a while, but this is the last message seen before the hang. >>> >>> >>> Hi, (adding dri-devel mailing list) >>> >>> >>> I started seeing this problem on 3.5-rc6. >>> >>> AFAICT, the system is not actually hung, it's just that no output >>> is showing up on the real (physical) output device (display) -- it's >>> going somewhere else (or to the bit bucket). >>> >> >> Can we bisect this at all? I'll try. >> I worry the intel one will bisect to where we moved the conflict >> resolution earlier, but I'd like to see if applying that patch earlier >> causes the issue, since radeon has it. >> >> I haven't reproduced this on any hw I own, I also can't get it under qemu. > > I'm also wondering whether this grub2 related in some way, grub2 is > starting to mess with the graphics adapter pointlessly. I'm using lilo, not grub. -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/3] Runtime Interpreted Power Sequences
On Thu, Aug 16, 2012 at 11:10:30AM -1000, Mitch Bradley wrote: > On 8/16/2012 8:38 AM, Stephen Warren wrote: > > Device tree bindings shouldn't reference Linux documentation; the > > bindings are supposed to be OS-agnostic. > While it is true that bindings should try to be OS-agnostic, there is > the practical matter of where to put documentation so that it is widely > accessible. The Linux source tree is one of the most accessible things > there is, considering how widely it is replicated. > As the original instigator of the policy that the device tree should > describe the hardware "OS-neutrally", I personally don't have a problem > with bindings referring to Linux documentation. I wouldn't like > references to proprietary and inaccessible documentation. OS agnosticness isn't the only issue here - the other problem with using Linux documentation is that except for things that are specifically userspace interfaces and the DT bindings nothing is intended to be stable so bindings defined in terms of Linux documentation may randomly change. We're not doing an awesome job of that with DT right now but we should try and so we ought to avoid including non-ABI things in ABIs like this. signature.asc Description: Digital signature
Re: mdraid6 problem post 3.5.0
On Fri, 17 Aug 2012 18:30:11 -0400 John Drescher wrote: > For the last few weeks I have been doing some reliability testing on a > mdraid6 array. One of my test was to physically hot remove a raid > member disk. This worked flawlessly with gentoo-sources-3.5.0 for the > 5 or so times I tried it with my 12 disk + 1 spare mdraid6 array. > After pulling a disk a few seconds later the array automatically > rebuilds with a spare and after finishing all data checks out via > btrfs a scrub. However trying this with gentoo-sources-3.5.2 or the > latest kernel.org git sources the machine does not start the rebuild > and any access to /proc/mdstat or and disk access that is not in cache > for that array just leads to an a long (possibly infinite) wait > eventually forcing me to have to use the reset button when the sysrq > key combinations fail to shut down the machine. I do see some kernel > debug message in the console alt-ctrl-f12 but I was unable to save > that to copy. > > Is this a known problem? If not it may be possible that I could bisect > this next week to the patch that causes this behavior. > Thanks for the report. The problem is not known to me.. There are no changes to raid6 between 3.5.0 and 3.5.2, so unless gentoo broke something (unlikely) this is very strange. A digital-photo of the debug messages might be useful if you can catch that. Setting up a network console to capture messages isn't too hard if you have another machine with a wired network connection. See Documentation/networking/netconsole.txt If you can set that us, then alt-sysrq-T might provide useful info. NeilBrown signature.asc Description: PGP signature
Re: mdraid6 problem post 3.5.0
On Fri, Aug 17, 2012 at 6:30 PM, John Drescher wrote: > For the last few weeks I have been doing some reliability testing on a > mdraid6 array. One of my test was to physically hot remove a raid > member disk. This worked flawlessly with gentoo-sources-3.5.0 for the > 5 or so times I tried it with my 12 disk + 1 spare mdraid6 array. > After pulling a disk a few seconds later the array automatically > rebuilds with a spare and after finishing all data checks out via > btrfs a scrub. However trying this with gentoo-sources-3.5.2 or the > latest kernel.org git sources the machine does not start the rebuild > and any access to /proc/mdstat or and disk access that is not in cache > for that array just leads to an a long (possibly infinite) wait > eventually forcing me to have to use the reset button when the sysrq > key combinations fail to shut down the machine. I do see some kernel > debug message in the console alt-ctrl-f12 but I was unable to save > that to copy. > > Is this a known problem? If not it may be possible that I could bisect > this next week to the patch that causes this behavior. > The same problem appears on gentoo-sources-3.5.1 so it appears this problem was introduced between kernels 3.5.0 and 3.5.1. I will have to debug this next week.. John -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver
On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie wrote: > On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap wrote: >> On 08/17/2012 03:25 PM, Justin M. Forbes wrote: >> >>> for , we have verified cases on inteldrmfb, radeondrmfb, and >>> cirrusdrmfb. >>> >>> This is the last message displayed before the system hangs. This seems >>> to be hitting a large number of users in Fedora, though certainly not >>> everyone. This started happening with the 3.5 updates, and is still an >>> issue. It appears to be a race condition, because various things have >>> allowed boot to continue for some users, though there is no clear work >>> around. Has anyone else run across this? Any ideas. For more >>> background we have the following bugs: >>> >>> inteldrmfb: >>> https://bugzilla.redhat.com/show_bug.cgi?id=843826 >>> >>> radeondrmfb: >>> https://bugzilla.redhat.com/show_bug.cgi?id=845745 >>> >>> cirrusdrmfb : >>> https://bugzilla.redhat.com/show_bug.cgi?id=843860 >>> >>> It should be noted that the conflicting fb hw usage message is not new, >>> it has been around for a while, but this is the last message seen before >>> the hang. >> >> >> Hi, (adding dri-devel mailing list) >> >> >> I started seeing this problem on 3.5-rc6. >> >> AFAICT, the system is not actually hung, it's just that no output >> is showing up on the real (physical) output device (display) -- it's >> going somewhere else (or to the bit bucket). >> > > Can we bisect this at all? > > I worry the intel one will bisect to where we moved the conflict > resolution earlier, but I'd like to see if applying that patch earlier > causes the issue, since radeon has it. > > I haven't reproduced this on any hw I own, I also can't get it under qemu. I'm also wondering whether this grub2 related in some way, grub2 is starting to mess with the graphics adapter pointlessly. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver
On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap wrote: > On 08/17/2012 03:25 PM, Justin M. Forbes wrote: > >> for , we have verified cases on inteldrmfb, radeondrmfb, and >> cirrusdrmfb. >> >> This is the last message displayed before the system hangs. This seems >> to be hitting a large number of users in Fedora, though certainly not >> everyone. This started happening with the 3.5 updates, and is still an >> issue. It appears to be a race condition, because various things have >> allowed boot to continue for some users, though there is no clear work >> around. Has anyone else run across this? Any ideas. For more >> background we have the following bugs: >> >> inteldrmfb: >> https://bugzilla.redhat.com/show_bug.cgi?id=843826 >> >> radeondrmfb: >> https://bugzilla.redhat.com/show_bug.cgi?id=845745 >> >> cirrusdrmfb : >> https://bugzilla.redhat.com/show_bug.cgi?id=843860 >> >> It should be noted that the conflicting fb hw usage message is not new, >> it has been around for a while, but this is the last message seen before >> the hang. > > > Hi, (adding dri-devel mailing list) > > > I started seeing this problem on 3.5-rc6. > > AFAICT, the system is not actually hung, it's just that no output > is showing up on the real (physical) output device (display) -- it's > going somewhere else (or to the bit bucket). > Can we bisect this at all? I worry the intel one will bisect to where we moved the conflict resolution earlier, but I'd like to see if applying that patch earlier causes the issue, since radeon has it. I haven't reproduced this on any hw I own, I also can't get it under qemu. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/2] mfd: dt: tps6586x: Add power off control
nvpublic > On Fri, Aug 17, 2012 at 02:16:28AM -0700, Bill Huang wrote: > [...] > > diff --git a/drivers/mfd/tps6586x.c b/drivers/mfd/tps6586x.c > [...] > > @@ -505,6 +519,11 @@ static int __devinit tps6586x_i2c_probe(struct > > i2c_client *client, > > goto err_add_devs; > > } > > > > + tps6586x_dev = >dev; > > + > > + if (pdata->pm_off && !pm_power_off) > > + pm_power_off = tps6586x_power_off; > > + > > I think the assignment of tps6586x_dev needs to go inside the if block as > well. Otherwise it might be > overwritten by another instance for systems that actually have more than one > tps6586x. Since currently > the driver can't be built as a module it probably makes little sense to clean > this up in .remove(), > but it might still be worth adding so it isn't forgotten if and when somebody > tries to convert the > driver to a module. > Thanks, good point. > I should note that I don't like very much how the pm_power_off works. > Maybe this should really be changed to allow passing a context for the > function to work from. > Something like: > > pm_power_off = tps6586x_power_off; > pm_power_off_data = >dev; > > Where pm_power_off() would receive pm_power_off_data as an argument. > > Even that's not very pretty. On the other hand this doesn't really buy us > much because only the > storage location of the variable would change and nothing else. But it would > still make the > association of the data clearer. > > Thierry > > * Unknown Key > * 0x7F3EB3A1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.0+ NFS issues (bisected)
On Fri, Aug 17, 2012 at 04:08:07PM -0400, J. Bruce Fields wrote:
> Wait a minute, that assumption's a problem because that calculation
> depends in part on xpt_reserved, which is changed here
>
> In particular, svc_xprt_release() calls svc_reserve(rqstp, 0), which
> subtracts rqstp->rq_reserved and then calls svc_xprt_enqueue, now with a
> lower xpt_reserved value. That could well explain this.
So, maybe something like this?
--b.
commit c8136c319ad85d0db870021fc3f9074d37f26d4a
Author: J. Bruce Fields
Date: Fri Aug 17 17:31:53 2012 -0400
svcrpc: don't add to xpt_reserved till we receive
The rpc server tries to ensure that there will be room to send a reply
before it receives a request.
It does this by tracking, in xpt_reserved, an upper bound on the total
size of the replies that is has already committed to for the socket.
Currently it is adding in the estimate for a new reply *before* it
checks whether there is space available. If it finds that there is not
space, it then subtracts the estimate back out.
This may lead the subsequent svc_xprt_enqueue to decide that there is
space after all.
The results is a svc_recv() that will repeatedly return -EAGAIN, causing
server threads to loop without doing any actual work.
Reported-by: Michael Tokarev
Signed-off-by: J. Bruce Fields
diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
index ec99849a..59ff3a3 100644
--- a/net/sunrpc/svc_xprt.c
+++ b/net/sunrpc/svc_xprt.c
@@ -366,8 +366,6 @@ void svc_xprt_enqueue(struct svc_xprt *xprt)
rqstp, rqstp->rq_xprt);
rqstp->rq_xprt = xprt;
svc_xprt_get(xprt);
- rqstp->rq_reserved = serv->sv_max_mesg;
- atomic_add(rqstp->rq_reserved, >xpt_reserved);
pool->sp_stats.threads_woken++;
wake_up(>rq_wait);
} else {
@@ -644,8 +642,6 @@ int svc_recv(struct svc_rqst *rqstp, long timeout)
if (xprt) {
rqstp->rq_xprt = xprt;
svc_xprt_get(xprt);
- rqstp->rq_reserved = serv->sv_max_mesg;
- atomic_add(rqstp->rq_reserved, >xpt_reserved);
/* As there is a shortage of threads and this request
* had to be queued, don't allow the thread to wait so
@@ -743,6 +739,10 @@ int svc_recv(struct svc_rqst *rqstp, long timeout)
len = xprt->xpt_ops->xpo_recvfrom(rqstp);
dprintk("svc: got len=%d\n", len);
}
+ if (len > 0) {
+ rqstp->rq_reserved = serv->sv_max_mesg;
+ atomic_add(rqstp->rq_reserved, >xpt_reserved);
+ }
svc_xprt_received(xprt);
/* No data, incomplete (TCP) read, or accept() */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] staging: zcache+ramster: move to new code base and re-merge
On 08/16/2012 06:08 PM, Greg KH wrote: > On a larger note, I _really_ don't want a set of 'delete and then add it > back' set of patches. That destroys all of the work that people had > done up until now on the code base. > > I understand your need, and want, to start fresh, but you still need to > abide with the "evolve over time" model here. Surely there is some path > from the old to the new codebase that you can find? I very much agree that this is the wrong way to do this. I can't possibly inspect the code changes in this format, so I'll just comment on some high level changes and mention some performance results. I like frontswap reclaiming memory from cleancache. I think that would work better than having the pages go back to the kernel-wide page pool using the shrinker interface. That being said, I can't test the impact of this alone because all these changes are being submitted together. I also like the sysfs->debugfs cleanup and zbud being moved into its own file. I do _not_ support replacing zsmalloc with zbud: https://lkml.org/lkml/2012/8/14/347 I do not support the integration of ramster mixed in with all the rest of these changes. I have no way to see or measure the impact of the ramster code. I ran my kernel building benchmark twice on an unmodified v3.5 kernel with zcache and then with these changes. On none-low memory pressure, <16 threads, they worked roughly the same with low swap volume. However, in mid-high pressure, >20 threads, these changes degraded zcache runtime and I/O savings by 30-80%. I would suspect the low-density storage of zbud as the culprit; however I can't confirm this because, again, it all one huge change. Some smaller issues: 1. This patchset breaks the build when CONFIG_SWAP in not set. FRONTSWAP depends on SWAP, but ZCACHE _selects_ FRONTSWAP. If ZCACHE is selected and FRONTSWAP can't be selected because SWAP isn't selected, then there is a break. 2. I get about 8 unsued/uninit'ed variable warnings at compile time. So I can't support this patchset, citing the performance degradation and the fact that this submission is unreviewable due to it being one huge monolithic patchset on top of an existing codebase. Seth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver
On 08/17/2012 03:25 PM, Justin M. Forbes wrote: > for , we have verified cases on inteldrmfb, radeondrmfb, and > cirrusdrmfb. > > This is the last message displayed before the system hangs. This seems > to be hitting a large number of users in Fedora, though certainly not > everyone. This started happening with the 3.5 updates, and is still an > issue. It appears to be a race condition, because various things have > allowed boot to continue for some users, though there is no clear work > around. Has anyone else run across this? Any ideas. For more > background we have the following bugs: > > inteldrmfb: > https://bugzilla.redhat.com/show_bug.cgi?id=843826 > > radeondrmfb: > https://bugzilla.redhat.com/show_bug.cgi?id=845745 > > cirrusdrmfb : > https://bugzilla.redhat.com/show_bug.cgi?id=843860 > > It should be noted that the conflicting fb hw usage message is not new, > it has been around for a while, but this is the last message seen before > the hang. Hi, (adding dri-devel mailing list) I started seeing this problem on 3.5-rc6. AFAICT, the system is not actually hung, it's just that no output is showing up on the real (physical) output device (display) -- it's going somewhere else (or to the bit bucket). -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
mdraid6 problem post 3.5.0
For the last few weeks I have been doing some reliability testing on a mdraid6 array. One of my test was to physically hot remove a raid member disk. This worked flawlessly with gentoo-sources-3.5.0 for the 5 or so times I tried it with my 12 disk + 1 spare mdraid6 array. After pulling a disk a few seconds later the array automatically rebuilds with a spare and after finishing all data checks out via btrfs a scrub. However trying this with gentoo-sources-3.5.2 or the latest kernel.org git sources the machine does not start the rebuild and any access to /proc/mdstat or and disk access that is not in cache for that array just leads to an a long (possibly infinite) wait eventually forcing me to have to use the reset button when the sysrq key combinations fail to shut down the machine. I do see some kernel debug message in the console alt-ctrl-f12 but I was unable to save that to copy. Is this a known problem? If not it may be possible that I could bisect this next week to the patch that causes this behavior. -- John M. Drescher -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver
for , we have verified cases on inteldrmfb, radeondrmfb, and cirrusdrmfb. This is the last message displayed before the system hangs. This seems to be hitting a large number of users in Fedora, though certainly not everyone. This started happening with the 3.5 updates, and is still an issue. It appears to be a race condition, because various things have allowed boot to continue for some users, though there is no clear work around. Has anyone else run across this? Any ideas. For more background we have the following bugs: inteldrmfb: https://bugzilla.redhat.com/show_bug.cgi?id=843826 radeondrmfb: https://bugzilla.redhat.com/show_bug.cgi?id=845745 cirrusdrmfb : https://bugzilla.redhat.com/show_bug.cgi?id=843860 It should be noted that the conflicting fb hw usage message is not new, it has been around for a while, but this is the last message seen before the hang. Thanks, Justin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/4] promote zcache from staging
> From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] > Subject: Re: [PATCH 0/4] promote zcache from staging > > On 08/09/2012 03:20 PM, Dan Magenheimer wrote > > I also wonder if you have anything else unusual in your > > test setup, such as a fast swap disk (mine is a partition > > on the same rotating disk as source and target of the kernel build, > > the default install for a RHEL6 system)? > > I'm using a normal SATA HDD with two partitions, one for > swap and the other an ext3 filesystem with the kernel source. > > > Or have you disabled cleancache? > > Yes, I _did_ disable cleancache. I could see where having > cleancache enabled could explain the difference in results. Sorry to beat a dead horse, but I meant to report this earlier in the week and got tied up by other things. I finally got my test scaffold set up earlier this week to try to reproduce my "bad" numbers with the RHEL6-ish config file. I found that with "make -j28" and "make -j32" I experienced __DATA CORRUPTION__. This was repeatable. The type of error led me to believe that the problem was due to concurrency of cleancache reclaim. I did not try with cleancache disabled to prove/support this theory but it is consistent with the fact that you (Seth) have not seen a similar problem and has disabled cleancache. While this problem is most likely in my code and I am suitably chagrined, it re-emphasizes the fact that the current zcache in staging is 20-month old "demo" code. The proposed new zcache codebase handles concurrency much more effectively. I'll be away from email for a few days now. Dan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
root=PARTUUID for MBR/NT disk signatures?
I was considering extending the kernel command-line option
root=PARTUUID= to also support MBR (NT disk signatures). I was thinking
of a syntax along the lines of:
root=PARTUUID=-PP[/PARTNROFF=%d]
... where is the hex representation of the NT disk signature,
and PP is the hex representation of the partition number. Like GPT,
/PARTNROFF could be used too if desired.
Related, I was thinking of changing struct partition_meta_info's uuid
field to be a string, so that it could simply be strcmp'd against the
UUID value on the kernel command-line. That way, the type of the UUID is
irrelevant.
Does anyone have any objection to that?
The reason I aim for that syntax rather than say:
root=MBRSIG=-PP[/PARTNROFF=%d]
... is to allow boot-loaders (e.g. U-Boot on ARM) to store just the
partition ID in a variable, and prepend all the Linux-specific stuff on
the front, e.g.
# For GPT:
setenv kernel_part_uuid b2f82cda-2535-4779-b467-094a210fbae7
# For MBR:
setenv kernel_part_uuid -PP
In fact, those hard-coded statements would probably be replaced with a
run-time command:
part uuid mmc 0:1 kernel_part_uuid
# Then in a common script:
setenv bootargs root=PARTUUID=${kernel_part_uuid}
Otherwise, the value of the uuid variable (or result of the "part uuid"
command) would need to prepend the PARTUUID= or MBRSIG= to the "uuid"
variable's value, and that's probably Linux-specific rather than part of
a generic UUID for the partition.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 0/3] staging: zcache+ramster: move to new code base and re-merge
[V2 fixes patch submission errors; no code changes] This patchset moves both the original "demo" zcache (in staging since 2.6.29) and ramster (in staging since 3.4) to a new stable code base which re-merges duplicate code and resolves various serious design flaws needed to allow progress in promoting zcache (and ramster) out of staging. An overview of the zcache rewrite is in the git commit of the new zcache patch. A significant item of debate in the new codebase is the removal of zsmalloc. This removal may be temporary if zsmalloc is enhanced with necessary features to meet the needs of the new zcache codebase. Justification for the change can be found at http://lkml.org/lkml/2012/8/15/292 While this new codebase is far from perfect (and thus remains in staging), the foundation is now cleaner, more stable, more maintainable, and much better commented. Signed-off-by: Dan Magenheimer --- Diffstat: drivers/staging/Kconfig|6 +- drivers/staging/Makefile |3 +- drivers/staging/ramster/Kconfig| 13 - drivers/staging/ramster/Makefile |1 - drivers/staging/ramster/TODO | 13 - drivers/staging/ramster/cluster/Makefile |3 - drivers/staging/ramster/cluster/heartbeat.c| 464 --- drivers/staging/ramster/cluster/heartbeat.h| 87 - drivers/staging/ramster/cluster/masklog.c | 155 - drivers/staging/ramster/cluster/masklog.h | 220 -- drivers/staging/ramster/cluster/nodemanager.c | 992 -- drivers/staging/ramster/cluster/nodemanager.h | 88 - .../staging/ramster/cluster/ramster_nodemanager.h | 39 - drivers/staging/ramster/cluster/tcp.c | 2256 - drivers/staging/ramster/cluster/tcp.h | 159 - drivers/staging/ramster/cluster/tcp_internal.h | 248 -- drivers/staging/ramster/r2net.c| 401 --- drivers/staging/ramster/ramster.h | 118 - drivers/staging/ramster/tmem.c | 851 - drivers/staging/ramster/tmem.h | 244 -- drivers/staging/ramster/xvmalloc.c | 509 --- drivers/staging/ramster/xvmalloc.h | 30 - drivers/staging/ramster/xvmalloc_int.h | 95 - drivers/staging/ramster/zcache-main.c | 3320 drivers/staging/ramster/zcache.h | 22 - drivers/staging/zcache/Kconfig | 23 +- drivers/staging/zcache/Makefile|5 +- drivers/staging/zcache/ramster.h | 59 + drivers/staging/zcache/ramster/heartbeat.c | 462 +++ drivers/staging/zcache/ramster/heartbeat.h | 87 + drivers/staging/zcache/ramster/masklog.c | 155 + drivers/staging/zcache/ramster/masklog.h | 220 ++ drivers/staging/zcache/ramster/nodemanager.c | 995 ++ drivers/staging/zcache/ramster/nodemanager.h | 88 + drivers/staging/zcache/ramster/r2net.c | 414 +++ drivers/staging/zcache/ramster/ramster.c | 985 ++ drivers/staging/zcache/ramster/ramster.h | 161 + .../staging/zcache/ramster/ramster_nodemanager.h | 39 + drivers/staging/zcache/ramster/tcp.c | 2253 + drivers/staging/zcache/ramster/tcp.h | 159 + drivers/staging/zcache/ramster/tcp_internal.h | 248 ++ drivers/staging/zcache/tmem.c | 376 ++- drivers/staging/zcache/tmem.h | 83 +- drivers/staging/zcache/zbud.c | 1060 +++ drivers/staging/zcache/zbud.h | 33 + drivers/staging/zcache/zcache-main.c | 2322 ++ drivers/staging/zcache/zcache.h| 53 + 47 files changed, 8842 insertions(+), 11775 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: max8907: Fix n_voltages for MAX8907B SD1
On Thu, Aug 16, 2012 at 12:26:02PM +0800, Axel Lin wrote: > For linear voltage mapping, the n_voltages is (max - min) / step + 1 Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: powerpc/perf: hw breakpoints return ENOSPC
Frederic Weisbecker wrote:
> On Thu, Aug 16, 2012 at 02:23:54PM +1000, Michael Neuling wrote:
> > Hi,
> >
> > I've been trying to get hardware breakpoints with perf to work on POWER7
> > but I'm getting the following:
> >
> > % perf record -e mem:0x1000 true
> >
> > Error: sys_perf_event_open() syscall returned with 28 (No space left on
> > device). /bin/dmesg may provide additional information.
> >
> > Fatal: No CONFIG_PERF_EVENTS=y kernel support configured?
> >
> > true: Terminated
> >
> > (FWIW adding -a and it works fine)
> >
> > Debugging it seems that __reserve_bp_slot() is returning ENOSPC because
> > it thinks there are no free breakpoint slots on this CPU.
> >
> > I have a 2 CPUs, so perf userspace is doing two perf_event_open syscalls
> > to add a counter to each CPU [1]. The first syscall succeeds but the
> > second is failing.
> >
> > On this second syscall, fetch_bp_busy_slots() sets slots.pinned to be 1,
> > despite there being no breakpoint on this CPU. This is because the call
> > the task_bp_pinned, checks all CPUs, rather than just the current CPU.
> > POWER7 only has one hardware breakpoint per CPU (ie. HBP_NUM=1), so we
> > return ENOSPC.
> >
> > The following patch fixes this by checking the associated CPU for each
> > breakpoint in task_bp_pinned. I'm not familiar with this code, so it's
> > provided as a reference to the above issue.
> >
> > Mikey
> >
> > 1. not sure why it doesn't just do one syscall and specify all CPUs, but
> > that's another issue. Using two syscalls should work.
>
> This patch seems to make sense. I'll try it and run some tests.
> Can I have your Signed-off-by ?
Of course...
Signed-off-by: Michael Neuling
>
> Thanks.
>
> >
> > diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c
> > index bb38c4d..e092daa 100644
> > --- a/kernel/events/hw_breakpoint.c
> > +++ b/kernel/events/hw_breakpoint.c
> > @@ -111,14 +111,16 @@ static unsigned int max_task_bp_pinned(int cpu, enum
> > bp_type_idx type)
> > * Count the number of breakpoints of the same type and same task.
> > * The given event must be not on the list.
> > */
> > -static int task_bp_pinned(struct perf_event *bp, enum bp_type_idx type)
> > +static int task_bp_pinned(int cpu, struct perf_event *bp, enum bp_type_idx
> > type)
> > {
> > struct task_struct *tsk = bp->hw.bp_target;
> > struct perf_event *iter;
> > int count = 0;
> >
> > list_for_each_entry(iter, _task_head, hw.bp_list) {
> > - if (iter->hw.bp_target == tsk && find_slot_idx(iter) == type)
> > + if (iter->hw.bp_target == tsk &&
> > + find_slot_idx(iter) == type &&
> > + cpu == iter->cpu)
> > count += hw_breakpoint_weight(iter);
> > }
> >
> > @@ -141,7 +143,7 @@ fetch_bp_busy_slots(struct bp_busy_slots *slots, struct
> > perf_event *bp,
> > if (!tsk)
> > slots->pinned += max_task_bp_pinned(cpu, type);
> > else
> > - slots->pinned += task_bp_pinned(bp, type);
> > + slots->pinned += task_bp_pinned(cpu, bp, type);
> > slots->flexible = per_cpu(nr_bp_flexible[type], cpu);
> >
> > return;
> > @@ -154,7 +156,7 @@ fetch_bp_busy_slots(struct bp_busy_slots *slots, struct
> > perf_event *bp,
> > if (!tsk)
> > nr += max_task_bp_pinned(cpu, type);
> > else
> > - nr += task_bp_pinned(bp, type);
> > + nr += task_bp_pinned(cpu, bp, type);
> >
> > if (nr > slots->pinned)
> > slots->pinned = nr;
> > @@ -188,7 +190,7 @@ static void toggle_bp_task_slot(struct perf_event *bp,
> > int cpu, bool enable,
> > int old_idx = 0;
> > int idx = 0;
> >
> > - old_count = task_bp_pinned(bp, type);
> > + old_count = task_bp_pinned(cpu, bp, type);
> > old_idx = old_count - 1;
> > idx = old_idx + weight;
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] spi: omap2-mcspi: Remove the call to platform_set_drvdata(pdev, NULL)
On Thu, Aug 16, 2012 at 08:49:30PM +0530, Shubhrajyoti D wrote: > Remove the call of platform_set_drvdata(pdev, NULL) as they are not > needed anymore. Applied, thanks. These calls were never *needed* people just like to put them in. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V3 08/14] Tools: hv: Gather DNS information
> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Friday, August 17, 2012 1:17 PM > To: KY Srinivasan > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; > o...@aepfle.de; > a...@canonical.com; b...@decadent.org.uk > Subject: Re: [PATCH V3 08/14] Tools: hv: Gather DNS information > > On Fri, Aug 17, 2012 at 05:07:22PM +, KY Srinivasan wrote: > > > On Thu, Aug 16, 2012 at 06:32:19PM -0700, K. Y. Srinivasan wrote: > > > > Now, gather DNS information. Invoke an external script (that can be > > > > distro dependent) to gather the DNS information. > > > > > > Where is that script? Why a script, this really isn't in a standard > > > method for all Linux distros? If not, why not work to do that like the > > > freedesktop.org people have done for other system configuration items? > > > > We debated this issue on this mailing list for a long time. The consensus > > was > that > > we would invoke external "distro" specific scripts for both configuring the > interface > > as well as gathering information that could not be gathered in a distro > independent > > fashion. That is what I have implemented here. This code specifies the > > interface > to this > > external script. If these external scripts are not there, it is not fatal - > > on the SET > side, > > the interface will not be configured and on the get side some attributes > > that are > to be > > gathered via these external scripts will not be collected. > > I've applied the first 7 patches here, feel free to submit the rest when > you answer the other questions I asked as well. Greg, I have tried to answer your questions in other emails I have sent out on this thread. To summarize, the current implementation (with external scripts) does not preclude using Network Manager where it makes sense (in the external scripts). If you think it will be useful to have example scripts, I could send the scripts I have used to test this code as example code. The reason I did not send the scripts is because (a) not having these scripts is not fatal to this code and (b) Given that this is a distro specific script, I did not want code checked into the kernel tree that was very distro specific. Let me know if I have addressed your concerns and if I can re-send the remaining 7 patches. Regards, K. Y -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 2/3] PM / Sleep: introduce dpm_for_each_dev
On Friday, August 17, 2012, Ming Lei wrote:
> dpm_list and its pm lock provide a good way to iterate all
> devices in system. Except this way, there is no other easy
> way to iterate devices in system.
>
> firmware loader need to cache firmware images for devices
> before system sleep, so introduce the function to meet its
> demand.
>
> Reported-by: Fengguang Wu
> Signed-off-by: Ming Lei
Well.
> ---
> drivers/base/power/main.c | 22 ++
> include/linux/pm.h|5 +
> 2 files changed, 27 insertions(+)
>
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index 57f5814..23b417f 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -1349,3 +1349,25 @@ int device_pm_wait_for_dev(struct device *subordinate,
> struct device *dev)
> return async_error;
> }
> EXPORT_SYMBOL_GPL(device_pm_wait_for_dev);
> +
> +/**
> + * dpm_for_each_dev - device iterator.
> + * @data: data for the callback.
> + * @fn: function to be called for each device.
> + *
> + * Iterate over devices in dpm_list, and call @fn for each device,
> + * passing it @data.
> + */
> +void dpm_for_each_dev(void *data, void (*fn)(struct device *, void *))
Is this function actually used more than once?
> +{
> + struct device *dev;
> +
> + if (!fn)
> + return;
> +
> + device_pm_lock();
> + list_for_each_entry(dev, _list, power.entry)
> + fn(dev, data);
> + device_pm_unlock();
> +}
> +EXPORT_SYMBOL_GPL(dpm_for_each_dev);
> diff --git a/include/linux/pm.h b/include/linux/pm.h
> index 44d1f23..007e687 100644
> --- a/include/linux/pm.h
> +++ b/include/linux/pm.h
> @@ -640,6 +640,7 @@ extern void __suspend_report_result(const char *function,
> void *fn, int ret);
> } while (0)
>
> extern int device_pm_wait_for_dev(struct device *sub, struct device *dev);
> +extern void dpm_for_each_dev(void *data, void (*fn)(struct device *, void
> *));
>
> extern int pm_generic_prepare(struct device *dev);
> extern int pm_generic_suspend_late(struct device *dev);
> @@ -679,6 +680,10 @@ static inline int device_pm_wait_for_dev(struct device
> *a, struct device *b)
> return 0;
> }
>
> +static inline void dpm_for_each_dev(void *data, void (*fn)(struct device *,
> void *))
> +{
> +}
> +
> #define pm_generic_prepare NULL
> #define pm_generic_suspend NULL
> #define pm_generic_resumeNULL
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RAID extremely slow
On Thursday 2012-07-26 03:00, Phil Turmel wrote: >> I used atop to show the transfer speeds to each drive. Here's a >> screenshot: >> http://img402.imageshack.us/img402/6484/screenshotfrom201207251.png > >[ The output of "lsdrv" [1] might be useful here, along with >"mdadm -D /dev/md0" and "mdadm -E /dev/[b-j]" ] >[1] http://github.com/pturmel/lsdrv lsdrv? Shows a bunch, but for this, using standard tools like lsscsi & lsblk seems sufficient :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC][PATCH 2/2] efi_pstore: Introducing workqueue updating sysfs entries
> You could, but why not always just schedule_work()? If we are hosed by > broken workqueue/scheduler locking, the user isn't going to > see those files in sysfs either way :) I'm not concern about failure of sysfs operations. In panic function call, panic_notifier_chain is kicked. Also users may expect the system reboots in panic case by specifying /proc/sys/kernel/panic. I just would like to avoid failures of those operations without adding unnecessary calls in the write callback. > If you are going to insist that we shouldn't schedule_work() in the other > cases, I'd prefer: > > /* The user may want to see an entry for this write in sysfs. */ if (reason > == KMSG_DUMP_OOPS) > schedule_work(...); > Thank you for your suggestion. I will update my patch by adding this logic above. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC]: drivers/tty: Folding Android's keyreset driver in sysRQ
On 08/17/2012 12:06 AM, mathieu.poir...@linaro.org wrote:
> +static int do_keyreset_event(struct sysrq_state *state,
> + unsigned int code, int value)
> +{
> + int ret;
> + int processed = 0;
> +
> + /* Is the code is of interestest to us */
> + if (!test_bit(code, state->keybit))
> + return processed;
> +
> + /* No need to take care of key up events */
> + if (!test_bit(code, state->key) == !value)
> + return processed;
> +
> + /* Record new entry */
> + __change_bit(code, state->key);
Hmm, this function is not atomic. Can do_keyreset_event be called
simultaneously from different CPUs? I suppose not...
> + if (value && !state->restart_disabled &&
> + state->key_down_ctn == state->key_down_target) {
> + state->restart_disabled = 1;
> + if (atomic_read(_requested))
> + panic(KERN_ERR "keyboard reset failed, %d - panic\n",
> + atomic_read(_requested));
panic() does not take KERN_* prefixes.
regards,
--
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/11] Request for Inclusion: kmem controller for memcg.
On Thu, Aug 9, 2012 at 6:01 AM, Glauber Costa wrote: > Hi, > > This is the first part of the kernel memory controller for memcg. It has been > discussed many times, and I consider this stable enough to be on tree. A > follow > up to this series are the patches to also track slab memory. They are not > included here because I believe we could benefit from merging them separately > for better testing coverage. If there are any issues preventing this to be > merged, let me know. I'll be happy to address them. > > The slab patches are also mature in my self evaluation and could be merged not > too long after this. For the reference, the last discussion about them > happened > at http://lwn.net/Articles/508087/ > > A (throwaway) git tree with them is placed at: > > git://github.com/glommer/linux.git kmemcg-slab I would like to make a kernel on the tree and run some perf tests on it. However the kernel doesn't boot due to "divide error: [#1] SMP". https://lkml.org/lkml/2012/5/21/502 I believe the issue has been fixed ( didn't look through) and can you do a rebase on your tree? --Ying > > A general explanation of what this is all about follows: > > The kernel memory limitation mechanism for memcg concerns itself with > disallowing potentially non-reclaimable allocations to happen in exaggerate > quantities by a particular set of processes (cgroup). Those allocations could > create pressure that affects the behavior of a different and unrelated set of > processes. > > Its basic working mechanism is to annotate some allocations with the > _GFP_KMEMCG flag. When this flag is set, the current process allocating will > have its memcg identified and charged against. When reaching a specific limit, > further allocations will be denied. > > One example of such problematic pressure that can be prevented by this work is > a fork bomb conducted in a shell. We prevent it by noting that processes use a > limited amount of stack pages. Seen this way, a fork bomb is just a special > case of resource abuse. If the offender is unable to grab more pages for the > stack, no new processes can be created. > > There are also other things the general mechanism protects against. For > example, using too much of pinned dentry and inode cache, by touching files an > leaving them in memory forever. > > In fact, a simple: > > while true; do mkdir x; cd x; done > > can halt your system easily because the file system limits are hard to reach > (big disks), but the kernel memory is not. Those are examples, but the list > certainly don't stop here. > > An important use case for all that, is concerned with people offering hosting > services through containers. In a physical box we can put a limit to some > resources, like total number of processes or threads. But in an environment > where each independent user gets its own piece of the machine, we don't want a > potentially malicious user to destroy good users' services. > > This might be true for systemd as well, that now groups services inside > cgroups. They generally want to put forward a set of guarantees that limits > the > running service in a variety of ways, so that if they become badly behaved, > they won't interfere with the rest of the system. > > There is, of course, a cost for that. To attempt to mitigate that, static > branches are used to make sure that even if the feature is compiled in with > potentially a lot of memory cgroups deployed this code will only be enabled > after the first user of this service configures any limit. Limits lower than > the user limit effectively means there is a separate kernel memory limit that > may be reached independently than the user limit. Values equal or greater than > the user limit implies only that kernel memory is tracked. This provides a > unified vision of "maximum memory", be it kernel or user memory. Because this > is all default-off, existing deployments will see no change in behavior. > > Glauber Costa (9): > memcg: change defines to an enum > kmem accounting basic infrastructure > Add a __GFP_KMEMCG flag > memcg: kmem controller infrastructure > mm: Allocate kernel pages to the right memcg > memcg: disable kmem code when not in use. > memcg: propagate kmem limiting information to children > memcg: allow a memcg with kmem charges to be destructed. > protect architectures where THREAD_SIZE >= PAGE_SIZE against fork > bombs > > Suleiman Souhlal (2): > memcg: Make it possible to use the stock for more than one page. > memcg: Reclaim when more than one page needed. > > include/linux/gfp.h | 10 +- > include/linux/memcontrol.h | 82 > include/linux/thread_info.h | 2 + > kernel/fork.c | 4 +- > mm/memcontrol.c | 443 > +--- > mm/page_alloc.c | 38 > 6 files changed, 546 insertions(+), 33 deletions(-) > > -- > 1.7.11.2 > > -- > To unsubscribe, send a message with 'unsubscribe
Re: [PATCH REBASE 1/2] i2c: tegra: I2_M_NOSTART functionality not supported in Tegra20
On 08/17/2012 01:02 PM, Laxman Dewangan wrote: > Tegra20 i2c controller does not support the continue transfer > which implements the I2C_M_NOSTART functionality of i2c > protocol mangling. > Removing the I2C_M_NOSTART functionality for Tegra20. > > Signed-off-by: Laxman Dewangan I tested both these patches and they work fine. I'll hold off applying them for a while for Wolfram to ack them. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 2/2] efi_pstore: Introducing workqueue updating sysfs entries
On Fri, Aug 17, 2012 at 2:15 PM, Seiji Aguchi wrote:
>
>> I'm not a fan of creating a periodic timer that wakes up here to check for
>> an event that should be considered very rare.
>>
>> Can this just become scheduled work? Scheduling work itself is a very
>> lightweight process and should be relatively safe to do from a
>> pstore write.
>
> I agree that the periodic timer is heavy a bit.
> But I would like to keep a write callback simple as much as possible in panic
> situation.
> For example, I'm concerned that efi_pstore hangs up due to some spin_locks
> related workqueue like gcwq->lock.
>
> Also, a situation which this workqueue is needed is just oops case because,
> system will be down and users can't access to sysfs files
> in other cases, panic, reboot and emergency_restart.
>
> So, Can I call schedule_work in oops case only as follows?
>
> efi_pstore_write()
> {
>
>
> if (reason != KMSG_DUMP_OOPS)
> return;
>
> schedule_work()
You could, but why not always just schedule_work()? If we are hosed
by broken workqueue/scheduler locking, the user isn't going to see
those files in sysfs either way :) If you are going to insist that we
shouldn't schedule_work() in the other cases, I'd prefer:
/* The user may want to see an entry for this write in sysfs. */
if (reason == KMSG_DUMP_OOPS)
schedule_work(...);
>
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 2/7] keys: initialize root uid and session keyrings early
Mimi Zohar writes:
> On Thu, 2012-08-16 at 15:59 -0400, Josh Boyer wrote:
>> On Thu, Aug 16, 2012 at 3:45 PM, Mimi Zohar wrote:
>> > On Thu, 2012-08-16 at 15:13 -0400, Josh Boyer wrote:
>> >> On Thu, Aug 16, 2012 at 3:08 PM, Mimi Zohar
>> >> wrote:
>> >> >> > +#include "internal.h"
>> >> >> > +static int __init init_root_keyring(void)
>> >> >> > +{
>> >> >> > + return install_user_keyrings();
>> >> >> > +}
>> >> >> > +
>> >> >> > +late_initcall(init_root_keyring);
>> >> >> > --
>> >> >>
>> >> >> Why is this in an entirely new file instead of just being added to
>> >> >> process_keys.c ?
>> >> >>
>> >> >> josh
>> >> >
>> >> > Only when "CONFIG_INTEGRITY_SIGNATURE" is selected, does this get built.
>> >>
>> >> Yes, I noticed that. It doesn't explain why it's in its own file. You
>> >> could accomplish the same thing by wrapping the function and initcall
>> >> in #ifdef CONFIG_INTEGRITY_SIGNATURE in process_keys.c.
>> >
>> > I was under the impression using 'ifdefs' in 'C' code was frowned upon
>> > (Documentation/SubmittingPatches section 2.2). This would be an
>> > exception?
>>
>> If it makes a big ugly mess it's frowned upon. But if you're adding 7
>> lines of code in a new file that will almost certainly never get more
>> code added to it, I'm not sure. IMHO, it can go into an existing file.
>> Others might disagree. Isn't Linux development fun?!
>
> This is just a case where if I had 'ifdef's in 'C' code, I'm sure
> someone would have complained. :)
Why does the code need to be dependent on security modules at all. The
code should work regardless either way.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scripts/patch-kernel fix
On Thursday 2012-07-26 12:10, Michal Marek wrote: >On 19.7.2012 23:49, Daniel Wisehart wrote: >> diff --git a/scripts/patch-kernel b/scripts/patch-kernel >> index d000ea3..a7672eb 100755 >> --- a/scripts/patch-kernel >> +++ b/scripts/patch-kernel >> @@ -226,7 +226,7 @@ fi >> >> # This all assumes a 2.6.x[.y] kernel tree. >> # Don't allow backwards/reverse patching. >> -if [ $STOPSUBLEVEL -lt $SUBLEVEL ]; then >> +if [ "$STOPSUBLEVEL"0 -lt "$SUBLEVEL"0 ]; then > >Hi Daniel, > >While this is correct, it is not obvious at first sight why you need to >multiply the numbers by 10. Or at least it was not obvious to me :). Word has it some really old shells nobody would use to compile Linux on interpret "" not as an empty argument, but as a non-existing argument, turning if [ "" != "" ] into essentially if [ != ]. Doing x10 avoids the uncertainity whether shells might attempt to interpret it as octal or not. So far the interpretation.. >Could you use the more common idiom 0$NUMBER? The shell interprets the >numbers as decimal, so it's works fine. Wonder what POSIX says about that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.6-rc2 Panic -- Network interrupt
Pete Clements writes: > Fyi: > Get below panic with 3.6-rc2 soon after boot (hand copy of screen). > [] ? tcp_v4_rcv+0x626/0x740 > [] ? ip_local_deliver_finish+0x6f/0x120 > [] ? ip_rcv+0x2b0/0x2b0 > [] ? ip_rcv_finish+0xe3/0x2d0 > [] ? __netif_receive_skb+03a8/0x4a0 > [] ? process_backlog+0x6b/0x100 > [] ? net_rx_action+07a/0x100 > [] ? __do_softirq+0x7f/0x120 > [] ? irq_enter+0x50/0x50 > > [] ? irq_exit+0x55/0x60 > [] ? do_IRQ+0x43/0xa0 > [] ? common_interrupt+0x29/0x30 > [] ? default_idle+0x14/0x30 > [] ? cpu_idle+0x26/0x40 > [] ? start_kernel+0x244/0x249 > [] ? kernel_init+0x16e/0x16e > Code: a9 ff ff e9 14 ff ff ff 90 8b 4a 48 83 e1 fe ff 41 40 89 48 78 8b 52 70 > 89 > 90 84 01 00 00 8b 51 58 85 d2 74 8c 8b 80 58 01 00 00 <8b> 52 14 89 50 68 c3 > 8d > b4 26 00 00 00 00 83 ec 84 0f b6 50 0e > EIP: [] inet6_sk_rx_dst_set+0x22/0x30 [ipv6] SS:ESP 0068:d7000dcc > CR2:00010016 > ---[ end trace 71149a645a111f5d ]--- > Kernel panic - not syncing: Fatal exception in interrupt Maybe related to the IPv6 early demux patches? Adding Cc's. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v2.6.34-stable 109/165] ntp: Fix leap-second hrtimer livelock
On Fri, Aug 17, 2012 at 09:43:37AM -0700, John Stultz wrote: > I also have another change pending in -tip that I've marked for > stable. Once that lands I'm planning on reviewing the current stable > trees to check that they have all the needed changes. John, for the record, I have already queued your whole 2.6.32 patchset as well as the aforementionned fix (ntp-Fix-STA_INS-DEL-clearing-bug). Thanks, Willy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC][PATCH 2/2] efi_pstore: Introducing workqueue updating sysfs entries
> I'm not a fan of creating a periodic timer that wakes up here to check for an
> event that should be considered very rare.
>
> Can this just become scheduled work? Scheduling work itself is a very
> lightweight process and should be relatively safe to do from a
> pstore write.
I agree that the periodic timer is heavy a bit.
But I would like to keep a write callback simple as much as possible in panic
situation.
For example, I'm concerned that efi_pstore hangs up due to some spin_locks
related workqueue like gcwq->lock.
Also, a situation which this workqueue is needed is just oops case because,
system will be down and users can't access to sysfs files
in other cases, panic, reboot and emergency_restart.
So, Can I call schedule_work in oops case only as follows?
efi_pstore_write()
{
if (reason != KMSG_DUMP_OOPS)
return;
schedule_work()
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [v2.6.34-stable 134/165] mm: avoid null pointer access in vm_struct via /proc/vmallocinfo
On Fri, Aug 17, 2012 at 02:26:15PM -0400, Paul Gortmaker wrote:
> On 12-08-17 11:22 AM, Herton Ronaldo Krzesinski wrote:
> > On Wed, Aug 15, 2012 at 03:47:58PM -0400, Paul Gortmaker wrote:
> >> From: Mitsuo Hayasaka
> >>
> >>---
> >> This is a commit scheduled for the next v2.6.34 longterm release.
> >>
> >> http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
> >> If you see a problem with using this for longterm, please comment.
> >>---
> >>
> >> commit f5252e009d5b87071a919221e4f6624184005368 upstream.
> >>
> >> The /proc/vmallocinfo shows information about vmalloc allocations in
> >> vmlist that is a linklist of vm_struct. It, however, may access pages
> >> field of vm_struct where a page was not allocated. This results in a null
> >> pointer access and leads to a kernel panic.
> >>
> >> Why this happens: In __vmalloc_node_range() called from vmalloc(), newly
> >> allocated vm_struct is added to vmlist at __get_vm_area_node() and then,
> >> some fields of vm_struct such as nr_pages and pages are set at
> >> __vmalloc_area_node(). In other words, it is added to vmlist before it is
> >> fully initialized. At the same time, when the /proc/vmallocinfo is read,
> >> it accesses the pages field of vm_struct according to the nr_pages field
> >> at show_numa_info(). Thus, a null pointer access happens.
> >>
> >> The patch adds the newly allocated vm_struct to the vmlist *after* it is
> >> fully initialized. So, it can avoid accessing the pages field with
> >> unallocated page when show_numa_info() is called.
> >>
> >> Signed-off-by: Mitsuo Hayasaka
> >> Cc: Andrew Morton
> >> Cc: David Rientjes
> >> Cc: Namhyung Kim
> >> Cc: "Paul E. McKenney"
> >> Cc: Jeremy Fitzhardinge
> >> Signed-off-by: Andrew Morton
> >> Signed-off-by: Linus Torvalds
> >> [PG: .34 has VMALLOC_START/END vs. start/end in f5252e009d5]
> >> Signed-off-by: Paul Gortmaker
> > [...]
> >
> > commit 1368edf0647ac112d8cfa6ce47257dc950c50f5c ("mm: vmalloc: check for
> > page allocation failure before vmlist insertion") addresses a regression
> > on this change, something to consider for inclusion in this stable
> > update as well.
>
> Thanks Herton.
>
> I've added Willy to CC, since v2.6.32.49 added f5252e but does
> not have 1368edf0 yet in any 2.6.32.x
Thank you Paul, much appreciated.
Queued for .60.
Willy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/8] fs, exportfs: Add export_encode_inode_fh helper
Al Viro writes: > On Thu, Aug 16, 2012 at 06:15:53PM +0400, Cyrill Gorcunov wrote: >> On Thu, Aug 16, 2012 at 02:03:00PM +, James Bottomley wrote: >> > > > What's wrong with saying "we don't support idiotify"? >> > > >> > > Al, we need some way to restore inotifies after checkpoint. >> > > At the very early versions of these patches I simply added >> > > dentry to the inotify mark thus once inotify created we always >> > > have a dentry to refer on in encode_fh, but I'm not sure if >> > > this will be good design. >> > >> > Actually, I was about to suggest this. This can be done internally >> > within fs/notify without actually modifying the syscall interface, can't >> > it, since they take a path which is used to obtain the inode? It looks >> > like the whole of the inotify interface could be internally recast to >> > use dentries instead of inodes. Unless I've missed something obvious? >> >> Well, after looking into do_sys_name_to_handle->exportfs_encode_fh >> sequence more precisely it seems it will be easier to extend >> exportfs_encode_fh to support inodes directly instead of playing >> with notify code (again, if i'm not missing something too). >> i'm cooking a patch to show (once it's tested i'll send it out). > > Good luck doing that with e.g. VFAT... And then there's such thing > as filesystems that don't have ->encode_fh() for a lot of very good > reasons; just try to do that on sysfs, for example. Or on ramfs, > for that matter... And while saying "you can't export that over > NFS" seems to work fine, idiotify-lovers will screech if you try > to ban their perversion of choice on those filesystems. For whatever it is worth inotify does not currently work on sysfs or procfs or any other filesystem that looks like a network filesystem and whose modifications don't proceed through the vfs like a normal filesystem. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ratelimit: check the condition in WARN_RATELIMIT first
On 08/17/2012 08:45 PM, Joe Perches wrote:
> On Fri, 2012-08-17 at 20:15 +0200, Jiri Slaby wrote:
>> On 08/17/2012 07:39 PM, Joe Perches wrote:
>>> On Fri, 2012-08-17 at 15:42 +0200, Jiri Slaby wrote:
Before calling __ratelimit in __WARN_RATELIMIT, check the condition
first. When this check was not there, we got constant income of:
tty_init_dev: 60 callbacks suppressed
tty_init_dev: 59 callbacks suppressed
>>> []
diff --git a/include/linux/ratelimit.h b/include/linux/ratelimit.h
>>> []
@@ -49,8 +49,9 @@ extern int ___ratelimit(struct ratelimit_state *rs,
const char *func);
#define __WARN_RATELIMIT(condition, state, format...) \
({\
int rtn = 0;\
- if (unlikely(__ratelimit(state))) \
- rtn = WARN(condition, format); \
+ int __rtcond = !!condition; \
+ if (unlikely(__rtcond && __ratelimit(state))) \
+ rtn = WARN(__rtcond, format); \
rtn;\
})
>>>
>>> Hi Jiri.
>>>
>>> This seems fine to me but are there any conditions that
>>> are computationally expensive?
>>
>> It's not about expensiveness of the computation. The complexity remained
>> the same except I moved the computation one layer up.
>
> If ratelimit(state) is not true, condition wasn't tested
> or performed at all. With this change, it's always done.
Ah, you meant this. Actually this was wrong/unexpected. When devs pass
something to a function/macro they expect it to be evaluated. Exactly once.
Like in this (maybe not so good) code:
void put_ref(int refcnt) {
WARN_RATELIMIT(!--refcnt, "refcnt reached 0 unexpectedly");
}
You want the refcnt to be decremented no matter what ratelimit() returns.
thanks,
--
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Software interrupt 0x8 guest crash from userspace: virtualbox emulation or guest kernel bug?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have observed a strange guest kernel crash in virtualbox and are currently trying to understand it. Since I have no real 32-bit Intel platform any more, I cannot verify that this crash would happen on native 32bit also, so perhaps someone could check that. I have also collected information about the crash [1], but currently fail to understand why this is happening. In short: Calling "int 0x8" in i386 guest on amd64 host crashes the guest. It seems, that "int 0x8" is handled by task gate, that fails to initialize "gs" correctly. The crash can be reproduced using [2], the same program does not crash the host. Due to lack of test platforms it is not clear, if that only affects virtual box guests. Questions: * Does this idt entry seem sane or could it be really broken? Code says ./arch/x86/kernel/traps.c: set_intr_gate_ist(8, _fault, DOUBLEFAULT_STACK); which seems consistent with observed idt setup. I'm not sure about privilege levels, is it possible to invoke this interrupt also on native systems and cause same behavior? * If broken, what is idt on native i386 system (not guest) on real 32-bit CPU? Could someone with such system send me: grep "idt_table" in System.map, "gdb --core /proc/kcore" and "x/64x [address of idt_table]" (see also [1])? * If broken, why? Same outcome on native i386 platform? * If not broken on native: why this interaction with virtualbox? hd [1] http://www.halfdog.net/Security/2012/VirtualBoxSoftwareInterrupt0x8GuestCrash/ [2] http://www.halfdog.net/Security/2012/VirtualBoxSoftwareInterrupt0x8GuestCrash/RtcInt.c - -- http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlAuqz8ACgkQxFmThv7tq+6CzwCginL/PMRVIKxRV4YRXtRIRF+O tO4An2KcZs5caaoTFu+UGJQLtFOrmKpS =9P33 -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ext4 write performance regression in 3.6-rc1 on RAID0/5
On Fri, 17 Aug 2012 22:25:26 +0800 Fengguang Wu
wrote:
> [CC md list]
>
> On Fri, Aug 17, 2012 at 09:40:39AM -0400, Theodore Ts'o wrote:
> > On Fri, Aug 17, 2012 at 02:09:15PM +0800, Fengguang Wu wrote:
> > > Ted,
> > >
> > > I find ext4 write performance dropped by 3.3% on average in the
> > > 3.6-rc1 merge window. xfs and btrfs are fine.
> > >
> > > Two machines are tested. The performance regression happens in the
> > > lkp-nex04 machine, which is equipped with 12 SSD drives. lkp-st02 does
> > > not see regression, which is equipped with HDD drives. I'll continue
> > > to repeat the tests and report variations.
> >
> > Hmm... I've checked out the commits in "git log v3.5..v3.6-rc1 --
> > fs/ext4 fs/jbd2" and I don't see anything that I would expect would
> > cause that. The are the lock elimination changes for Direct I/O
> > overwrites, but that shouldn't matter for your tests which are
> > measuring buffered writes, correct?
> >
> > Is there any chance you could do me a favor and do a git bisect
> > restricted to commits involving fs/ext4 and fs/jbd2?
>
> I noticed that the regressions all happen in the RAID0/RAID5 cases.
> So it may be some interactions between the RAID/ext4 code?
I'm aware of some performance regression in RAID5 which I will be drilling
down into next week. Some things are faster, but some are slower :-(
RAID0 should be unchanged though - I don't think I've changed anything there.
Looking at your numbers, JBOD ranges from +6.5% to -1.5%
RAID0 ranges from +4.0% to -19.2%
RAID5 ranges from +20.7% to -39.7%
I'm guessing + is good and - is bad?
The RAID5 numbers don't surprise me. The RAID0 do.
>
> I'll try to get some ext2/3 numbers, which should have less changes on the fs
> side.
Thanks. That will be useful.
NeilBrown
>
> wfg@bee /export/writeback% ./compare -g ext4 lkp-nex04/*/*-{3.5.0,3.6.0-rc1+}
>
>3.5.03.6.0-rc1+
>
> 720.62-1.5% 710.16
> lkp-nex04/JBOD-12HDD-thresh=1000M/ext4-100dd-1-3.5.0
> 706.04-0.0% 705.86
> lkp-nex04/JBOD-12HDD-thresh=1000M/ext4-10dd-1-3.5.0
> 702.86-0.2% 701.74
> lkp-nex04/JBOD-12HDD-thresh=1000M/ext4-1dd-1-3.5.0
> 702.41-0.0% 702.06
> lkp-nex04/JBOD-12HDD-thresh=1000M/ext4-1dd-2-3.5.0
> 779.52+6.5% 830.11
> lkp-nex04/JBOD-12HDD-thresh=100M/ext4-100dd-1-3.5.0
> 646.70+4.9% 678.59
> lkp-nex04/JBOD-12HDD-thresh=100M/ext4-10dd-1-3.5.0
> 704.49+2.6% 723.00
> lkp-nex04/JBOD-12HDD-thresh=100M/ext4-1dd-1-3.5.0
> 704.21+1.2% 712.47
> lkp-nex04/JBOD-12HDD-thresh=100M/ext4-1dd-2-3.5.0
> 705.26-1.2% 696.61
> lkp-nex04/JBOD-12HDD-thresh=8G/ext4-100dd-1-3.5.0
> 703.37+0.1% 703.76
> lkp-nex04/JBOD-12HDD-thresh=8G/ext4-10dd-1-3.5.0
> 701.66-0.1% 700.83
> lkp-nex04/JBOD-12HDD-thresh=8G/ext4-1dd-1-3.5.0
> 701.17+0.0% 701.36
> lkp-nex04/JBOD-12HDD-thresh=8G/ext4-1dd-2-3.5.0
> 675.08 -10.5% 604.29
> lkp-nex04/RAID0-12HDD-thresh=1000M/ext4-100dd-1-3.5.0
> 676.52-2.7% 658.38
> lkp-nex04/RAID0-12HDD-thresh=1000M/ext4-10dd-1-3.5.0
> 512.70+4.0% 533.22
> lkp-nex04/RAID0-12HDD-thresh=1000M/ext4-1dd-1-3.5.0
> 524.61-0.3% 522.90
> lkp-nex04/RAID0-12HDD-thresh=1000M/ext4-1dd-2-3.5.0
> 709.76 -15.7% 598.44
> lkp-nex04/RAID0-12HDD-thresh=100M/ext4-100dd-1-3.5.0
> 681.39-2.1% 667.25
> lkp-nex04/RAID0-12HDD-thresh=100M/ext4-10dd-1-3.5.0
> 524.16+0.8% 528.25
> lkp-nex04/RAID0-12HDD-thresh=100M/ext4-1dd-2-3.5.0
> 699.77 -19.2% 565.54
> lkp-nex04/RAID0-12HDD-thresh=8G/ext4-100dd-1-3.5.0
> 675.79-1.9% 663.17
> lkp-nex04/RAID0-12HDD-thresh=8G/ext4-10dd-1-3.5.0
> 484.84-7.4% 448.83
> lkp-nex04/RAID0-12HDD-thresh=8G/ext4-1dd-1-3.5.0
> 470.40-3.2% 455.31
> lkp-nex04/RAID0-12HDD-thresh=8G/ext4-1dd-2-3.5.0
> 167.97 -38.7% 103.03
> lkp-nex04/RAID5-12HDD-thresh=1000M/ext4-100dd-1-3.5.0
> 243.67-9.1% 221.41
> lkp-nex04/RAID5-12HDD-thresh=1000M/ext4-10dd-1-3.5.0
> 248.98 +12.2% 279.33
> lkp-nex04/RAID5-12HDD-thresh=1000M/ext4-1dd-1-3.5.0
> 208.45 +14.1% 237.86
> lkp-nex04/RAID5-12HDD-thresh=1000M/ext4-1dd-2-3.5.0
>71.18
RE: [RFC][PATCH 1/2] efivars: Disable external interrupt while holding efivars->lock
> This isn't necessary (nor desirable). If the API here is that we get called > from process context for ->open and ->close(), just use the > spin_lock_irq and spin_unlock_irq variants for these paths (avoiding the need > to remove the lock acquire in ->open and ->close. OK. I will update my patch based on your comment above. Thank you for your quick response. Seiji -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/1] trace: Move trace event enable from fs_initcall to early_initcall
On Fri, Aug 17, 2012 at 10:39:39AM -0400, Steven Rostedt wrote: > On Fri, 2012-08-17 at 11:04 -0300, Ezequiel Garcia wrote: > > On Fri, Aug 17, 2012 at 10:55 AM, Steven Rostedt > > wrote: > > > On Fri, 2012-08-17 at 08:01 -0300, Ezequiel Garcia wrote: > > > > > >> Regarding the 'complete solution': to be able to capture events from > > >> the very beggining... > > >> Have you thought about this? > > >> Could you give me a hint on how could I implement it? > > > > > > How far in the "beginning"? Before memory is set up? > > > > Yes. > > > > > I wouldn't do that. > > > > Yeah, perhaps it sounds crazy. It makes some sense for kmem events, though. > > It doesn't sound crazy, because I've done it before. There may be ways > to do it. > > > > > > I have in the past (set up before memory was finished being > > > initialized), but things have changed since then. > > > > > > One thing that we could do for those that want really early tracing, is > > > to add a config option to add a static temporary ring buffer, that gets > > > > Yes, something like this would be ideal. How would this ring buffer be > > allocated? > > Perhaps as static and __initdata? > > Yes. > > > This way it would be released afterwards, right? > > Correct. > > > > > > copied into the default ring buffer after memory is set up. That may be > > > the easiest way. > > > > > > Once memory is set up, the ring buffer can be allocated and events can > > > be traced, but the ring buffer needs to be set up first. All it would > > > take is some calls in init/main.c start_kernel() to the initialization. > > > > > > > Note that my main concern is on trace_events (kmem events to be precise). > > However this are registered through tracepoints and in turn this tracepoints > > depend on kmalloc and friends. So, right now is a chicken-egg problem. > > I don't think kmalloc is the issue. The big problem in front of you is > jump labels. That's what enables and disables trace points, and it gets > initialized just after memory is set up. You may have to force jump > labels off when doing early tracing :-/ Although I'm not sure it > requires allocations. > The only allocation jump labels should do is when modules are loaded. So I think you should be able to move them earlier, if need be. Thanks, -Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
