REMINDER

[ben.cj...@yahoo.com.hk]

Dear beneficiary,

This is to re-notify you of the $300,000.00 USD that was deposited
here in the western union office in your name is available for pickup.
Contact us via email for your M.T.C.N Numbers.

Contact Person:Mr. ben c john
Email: eric.joh...@yahoo.com.hk
Contact Phone : +44 7024043572
--
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] remove cpqarray from mainline kernel

[Hannes Reinecke]

On 10/17/2013 07:52 PM, Mike Miller wrote:
> From: Mike Miller 
> 
> cpqarray hasn't been used in over 12 years. It's doubtful that anyone still
> uses the board. It's time the driver was removed from the mainline kernel.
> The only updates these days are minor and mostly done by people outside of HP.
> 
> Signed-off-by: Mike Miller 
Finally.

All thumbs up for this.

Acked-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes Reinecke   zSeries & Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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] usb-storage: scsiglue: Changing the command result

[Vishal Annapurve]

Hi Alan,

What I wanted to say was If the bit US_FLIDX_TIMED_OUT can have more
meanings than timed out then maybe it would be best to override the
results after usb-storage is done with the command maybe in scsi layer
itself who aborted it in the first place.

My concern was that overriding the result in usb storage or scsi layers
will have more side effects than doing it in scsiglue.c.
And by scsi-usb storage bridge what I meant was specifically the code in 
scsiglue.

Question about your last mail, do you want to change all the occurrences of
DID_ABORT from usb-storage to DID_TIMEOUT?

Regards,
Vishal

-Original Message-
From: Alan Stern [mailto:st...@rowland.harvard.edu] 
Sent: Tuesday, October 15, 2013 10:22 PM
To: Vishal Annapurve
Cc: Ming Lei; Linux Kernel Mailing List; linux-usb
Subject: RE: [PATCH] usb-storage: scsiglue: Changing the command result

On Tue, 15 Oct 2013, Vishal Annapurve wrote:

> Hi Alan,
> 
> USB storage maybe just has to say that the abort occurred. By setting 
> the US_FLIDX_TIMED_OUT bit USB storage is getting signaled that the 
> reason was time out and the command is being aborted.

No.  By setting the US_FLIDX_TIMED_OUT bit, usb-storage indicates that the 
command was aborted.  This doesn't indicate anything about the reason for the 
abort.  (Maybe this bit's name wasn't chosen very well.)

> Now, it's arguable whether to change the implication of 
> US_FLIDX_TIMED_OUT bit for scsi - USB storage bridge or for entire usb 
> storage

I don't understand this.  What's the difference between "scsi - USB storage 
bridge" and "entire usb storage"?  Aren't they the same thing?

>  Or maybe scsi has
> decided to abort so it should override the result.

Of course the SCSI midlayer has decided to abort.  That's the only way this bit 
can get set.  But usb-storage doesn't know why SCSI decided to abort.

Alan Stern

--
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 2/3] PCI: Refactor MSI/MSIX mask restore code to fix interrupt lost issue

[Jingoo Han]

On Wednesday, October 16, 2013 3:33 PM, Zhenzhong Duan wrote:
> 
> Driver init call graph under baremetal:
> driver_init->
> msix_capability_init->
> msix_program_entries->
> msix_mask_irq->
> entry->masked = 1
> request_irq->
> __setup_irq->
> irq_startup->
> unmask_msi_irq->
> msix_mask_irq->
> entry->masked = 0;
> 
> So entry->masked is always updated with newest value and its value could be 
> used
> to restore to mask register in device.
> 
> But in initial domain (aka priviliged guest), it's different.
> Driver init call graph under initial domain:
> driver_init->
> msix_capability_init->
> msix_program_entries->
> msix_mask_irq->
> entry->masked = 1
> request_irq->
> __setup_irq->
> irq_startup->
> __startup_pirq->
> EVTCHNOP_bind_pirq hypercall(trap into Xen)
> [Xen:]
> pirq_guest_bind->
> startup_msi_irq->
> unmask_msi_irq->
> msi_set_mask_bit->
> entry->msi_attrib.masked = 0;
> 
> So entry->msi_attrib.masked in xen side always has newest value. entry->masked
> in initial domain is untouched and is 1 after msix_capability_init.
> 
> Based on above, it's Xen's duty to restore entry->msi_attrib.masked to device,
> but with current code, entry->masked is used and MSI-x interrupt is masked.
> 
> Before patch, restore call graph under initial domain:
> pci_reset_function->
> pci_restore_state->
> __pci_restore_msix_state->
> arch_restore_msi_irqs->
> xen_initdom_restore_msi_irqs->
> PHYSDEVOP_restore_msi hypercall (first mask restore)
> msix_mask_irq(entry, entry->masked) (second mask restore)
> 
> So msix_mask_irq call in initial domain call graph needs to be removed.
> 
> Based on this we can move the restore of the mask in default_restore_msi_irqs
> which would avoid restoring the invalid mask under Xen. Furthermore this
> simplifies the API by making everything related to restoring an MSI be in the
> platform specific APIs instead of just parts of it.
> 
> After patch, restore call graph under initial domain:
> pci_reset_function->
> pci_restore_state->
> __pci_restore_msix_state->
> arch_restore_msi_irqs->
> xen_initdom_restore_msi_irqs->
> PHYSDEVOP_restore_msi hypercall (first mask restore)
> 
> Logic for baremetal is not changed.
> Before patch, restore call graph under baremetal:
> pci_reset_function->
> pci_restore_state->
> __pci_restore_msix_state->
> arch_restore_msi_irqs->
> default_restore_msi_irqs->
> msix_mask_irq(entry, entry->masked) (first mask restore)
> 
> After patch, restore call graph under baremetal:
> pci_reset_function->
> pci_restore_state->
> __pci_restore_msix_state->
> arch_restore_msi_irqs->
> default_restore_msi_irqs->
> msix_mask_irq(entry, entry->masked) (first mask restore)
> 
> The process for MSI code is similiar.
> 
> Tested-by: Sucheta Chakraborty 
> Signed-off-by: Zhenzhong Duan 
> Acked-by: Konrad Rzeszutek Wilk 

Reviewed-by: Jingoo Han 

It looks good. Also, I tested this patch on Exynos5440.

Best regards,
Jingoo Han

--
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/3] PCI: Refactor restore_msi_irqs - code movement

[Jingoo Han]

On Wednesday, October 16, 2013 3:32 PM, Zhenzhong Duan wrote:
> 
> Move default_restore_msi_irqs down to reference msi_mask_irq and 
> msix_mask_irq.
> 
> This patch lays the groundwork for patch titled:
> 'PCI: Refactor MSI/MSIX mask restore code to fix interrupt lost issue'
> 
> Tested-by: Sucheta Chakraborty 
> Signed-off-by: Zhenzhong Duan 
> Acked-by: Konrad Rzeszutek Wilk 

Reviewed-by: Jingoo Han 

It looks good. Also, I tested this patch on Exynos5440.

Best regards,
Jingoo Han

--
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: How to set fops in "struct platform_pwm_backlight_data"?

[Mark Zhang]

On 10/17/2013 03:14 PM, Thierry Reding wrote:
> On Thu, Oct 17, 2013 at 02:49:57PM +0800, Mark Zhang wrote:
>> Hi,
>>
>> This is the first time I send mail to linux-pwm, I didn't read through
>> the mails in this list, so if somebody already asked this question, I'm
>> sorry about that.
>>
>> I wanna set some fops in "struct platform_pwm_backlight_data". But the
>> currrent probe function in pwm_bl.c says:
>>
>> ---
>> if (!data) {
>>  ret = pwm_backlight_parse_dt(>dev, );
>>  if (ret < 0) {
>>  dev_err(>dev, "failed to find platform data\n");
>>  return ret;
>>  }
>>
>>  data = 
>> }
>> ---
>>
>> This looks like if we set the platform data for pwm backlight device,
>> "pwm_backlight_parse_dt" will never have a chance to be called, which
>> means the stuffs I defined in backlight DT node will be ignored.
>>
>> If I don't set the platform data for pwm backlight device, according to
>> the pwm_backlight_probe, I will never have a chance to set some fops
>> which I need(like "notify", "check_fb"...).
>>
>> So, what I suppose to do now? Maybe there is a way to set function
>> pointers in DT?
> 
> Perhaps you could describe in more detail what you need the functions
> for.
> 

Okay, I just want to set the "notify" function pointer in "struct
platform_pwm_backlight_data", because I want to tune the brightness
value before the pwm-bl sets the brightness to hardware. I don't know
how to do that, unless we define the platform data explicitly.

Mark
> Generally you're not supposed to mix DT and platform data. Without more
> info that's about all I can say.
> 
> Thierry
> 
--
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] get_maintainer.pl incomplete output

[Joe Perches]

On Thu, 2013-10-17 at 12:12 -0700, Andrew Morton wrote:
> On Wed, 16 Oct 2013 20:51:18 -0700 (PDT) David Rientjes  
> wrote:
> 
> > I haven't looked closely at scripts/get_maintainer.pl, but I recently 
> > wrote a patch touching mm/vmpressure.c and it doesn't list the file's 
> > author, Anton Vorontsov .
> > 
> > Even when I do scripts/get_maintainer.pl -f mm/vmpressure.c, his entry is 
> > missing and git blame attributs >90% of the lines to his authorship.
> > 
> > $ ./scripts/get_maintainer.pl -f mm/vmpressure.c 
> > Tejun Heo  (commit_signer:6/7=86%)
> > Michal Hocko  (commit_signer:5/7=71%)
> > Andrew Morton  (commit_signer:4/7=57%)
> > Li Zefan  (commit_signer:3/7=43%)
> > "Kirill A. Shutemov"  (commit_signer:1/7=14%)
> > linux...@kvack.org (open list:MEMORY MANAGEMENT)
> > linux-kernel@vger.kernel.org (open list)
> 
> get_maintainer should, by default, answer the question "who should I
> email about this file".  It clearly isn't doing this, and that's a
> pretty big fail.
> 
> I've learned not to trust it, so when I use it I always have to check
> its homework with "git log | grep Author" :(
> 
> Joe, pretty please?

Try this:

It adds authored/lines_added/lines_deleted to rolestats

For instance:

$ ./scripts/get_maintainer.pl -f mm/vmpressure.c
Tejun Heo  
(commit_signer:6/7=86%,authored:3/7=43%,removed_lines:15/21=71%)
Michal Hocko  
(commit_signer:5/7=71%,authored:3/7=43%,added_lines:22/408=5%,removed_lines:6/21=29%)
Andrew Morton  (commit_signer:4/7=57%)
Li Zefan  (commit_signer:3/7=43%)
"Kirill A. Shutemov"  (commit_signer:1/7=14%)
Anton Vorontsov  
(authored:1/7=14%,added_lines:374/408=92%)
linux...@kvack.org (open list:MEMORY MANAGEMENT)
linux-kernel@vger.kernel.org (open list)

I haven't tested it much.

---

 scripts/get_maintainer.pl | 90 +++
 1 file changed, 84 insertions(+), 6 deletions(-)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 5e4fb14..ee9adb8 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -98,6 +98,7 @@ my %VCS_cmds_git = (
 "available" => '(which("git") ne "") && (-d ".git")',
 "find_signers_cmd" =>
"git log --no-color --follow --since=\$email_git_since " .
+   '--numstat --no-merges ' .
'--format="GitCommit: %H%n' .
  'GitAuthor: %an <%ae>%n' .
  'GitDate: %aD%n' .
@@ -106,6 +107,7 @@ my %VCS_cmds_git = (
" -- \$file",
 "find_commit_signers_cmd" =>
"git log --no-color " .
+   '--numstat ' .
'--format="GitCommit: %H%n' .
  'GitAuthor: %an <%ae>%n' .
  'GitDate: %aD%n' .
@@ -114,6 +116,7 @@ my %VCS_cmds_git = (
" -1 \$commit",
 "find_commit_author_cmd" =>
"git log --no-color " .
+   '--numstat ' .
'--format="GitCommit: %H%n' .
  'GitAuthor: %an <%ae>%n' .
  'GitDate: %aD%n' .
@@ -125,6 +128,7 @@ my %VCS_cmds_git = (
 "blame_commit_pattern" => "^([0-9a-f]+) ",
 "author_pattern" => "^GitAuthor: (.*)",
 "subject_pattern" => "^GitSubject: (.*)",
+"stat_pattern" => "(\\d+)\\t(\\d+)\\t\$file",
 );
 
 my %VCS_cmds_hg = (
@@ -152,6 +156,7 @@ my %VCS_cmds_hg = (
 "blame_commit_pattern" => "^([ 0-9a-f]+):",
 "author_pattern" => "^HgAuthor: (.*)",
 "subject_pattern" => "^HgSubject: (.*)",
+"stat_pattern" => "(\\d+)\t(\\d+)\t\$file",
 );
 
 my $conf = which_conf(".get_maintainer.conf");
@@ -1269,20 +1274,30 @@ sub extract_formatted_signatures {
 }
 
 sub vcs_find_signers {
-my ($cmd) = @_;
+my ($cmd, $file) = @_;
 my $commits;
 my @lines = ();
 my @signatures = ();
+my @authors = ();
+my @stats = ();
 
 @lines = &{$VCS_cmds{"execute_cmd"}}($cmd);
 
 my $pattern = $VCS_cmds{"commit_pattern"};
+my $author_pattern = $VCS_cmds{"author_pattern"};
+my $stat_pattern = $VCS_cmds{"stat_pattern"};
+
+$stat_pattern =~ s/(\$\w+)/$1/eeg; #interpolate $stat_pattern
 
 $commits = grep(/$pattern/, @lines);   # of commits
 
+@authors = grep(/$author_pattern/, @lines);
 @signatures = grep(/^[ \t]*${signature_pattern}.*\@.*$/, @lines);
+@stats = grep(/$stat_pattern/, @lines);
+
+#print("stats: <@stats>\n");
 
-return (0, @signatures) if !@signatures;
+return (0, @signatures, @authors) if !@signatures;
 
 save_commits_by_author(@lines) if ($interactive);
 save_commits_by_signer(@lines) if ($interactive);
@@ -1291,9 +1306,10 @@ sub vcs_find_signers {
@signatures = grep(!/${penguin_chiefs}/i, @signatures);
 }
 
+my ($author_ref, $authors_ref) = extract_formatted_signatures(@authors);
 my ($types_ref, $signers_ref) = extract_formatted_signatures(@signatures);
 
-return ($commits, @$signers_ref);
+return ($commits, $signers_ref, $authors_ref, \@stats);
 }
 
 sub vcs_find_author {
@@ -1849,7 +1865,12 @@ sub vcs_assign {
 

Re: [PATCH 00/23 v2] cleanup: introduce br/netdev/netif/wiphy__ratelimited() and use them to simplify code

[Joe Perches]

(resending to lists only because of multiple X's in the subject line)

On Fri, 2013-10-18 at 11:52 +0800, Kefeng Wang wrote:
> v1-v2:
> 
>   Introduce macro br/netdev/netif/wiphy_XXX_ratelimited() according
>   to Joe Perches's advice. The macros are similar to net_XXX_ratelimited()
>   which is more clarifying than net_ratelimited_function(), then use them
>   to simplify code.

There are some conceptual differences between these
implementations and other _ratelimited uses.

For every other subsystem but net, there is a per-location
struct ratelimit_state.

Here you've made the global net_ratelimit_state replace all
of these individual structs so there is some new interaction.

Dunno if that's good or bad.



--
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] x86, kdump: crashkernel=X try to reserve below 896M first, then try below 4G, then MAXMEM

[Yinghai Lu]

On Tue, Oct 15, 2013 at 7:48 AM, Vivek Goyal  wrote:
> On Mon, Oct 14, 2013 at 11:54:22AM -0700, Yinghai Lu wrote:
>> On Mon, Oct 14, 2013 at 4:46 AM, WANG Chao  wrote:
>> User should change crashkernel=X to crashkernel=X,high.
>
> I think if we can extend old syntax of crashkernel=X, then it makes life
> really easy for users.
>
>>
>> As user could forget to update kexec-tools to utilize ",high" feature, and 
>> get
>> kdump later fail later.
>
> Previously high reservation (reservation above 896M) will anyway fail. So
> instead of failing, if we try reservation in higher memory areas why that
> would break old kexec-tools?

If thel old kexec-tools would fail, we should let them fail early as possible,
do not reserve at first point.

>
> IOW, previously anyway kexec-tools will not work as no memory will be
> reserved in higher memory area. Now memory will be reserved but old
> kexec-tools should fail as it can't load in that area.
>
> If that works, then one would use crashkernel=X,high only if he is
> particualr that memory reservation comes from area above 4G (despite
> the fact that same memory could have been reserved below 4G too).

My point:
Push user to use ",high" as more as possible, so we only to handle one
path eventually.
for old kernel, leave them to use old grammer. do not need to change it.

Also boot loader should always have different entry for old kernel and
new kernel.

Thanks

Yinghai
--
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 net V2 1/2] virtio-net: don't respond to cpu hotplug notifier if we're not ready

[David Miller]

From: Rusty Russell 
Date: Fri, 18 Oct 2013 11:30:15 +1030

> Asking people to express 'CC: stable' in words is error-prone; if Dave
> wants to filter it, he's quite capable.

Filtering it one time is one thing.

Potentially acting on that filter 100 or so times a day...

That's completely another.
--
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 6/7] arm64, jump label: optimize jump label implementation

[Jiang Liu (Gerry)]

On 2013/10/17 23:27, Steven Rostedt wrote:

On Thu, 17 Oct 2013 22:40:32 +0800
Jiang Liu  wrote:



You could make the code more concise by limiting your patching ability to
branch immediates. Then a nop is simply a branch to the next instruction (I
doubt any modern CPUs will choke on this, whereas the architecture requires
a NOP to take time).

I guess a NOP should be more effecient than a "B #4" on real CPUs:)


Well, I was actually questioning that. A NOP *has* to take time (the
architecture prevents implementations from discaring it) whereas a static,
unconditional branch will likely be discarded early on by CPUs with even
simple branch prediction logic.

I naively thought "NOP" is cheaper than a "B" :(
Will use a "B #1" to replace "NOP".



Really?? What's the purpose of a NOP then? It seems to me that an
architecture is broken if a NOP is slower than a static branch.

-- Steve

Hi Steve and Will,
I have discussed this with one of our chip design members.
He thinks "NOP" should be better than "B #1" because jump instruction
is one of the most complex instructions for microarchitecture, which
may stall the pipeline. And NOP should be friendly enough for all
microarchitectures. So I will keep the "NOP" version.
Thanks!
Gerry


--
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/3] irq: Fix some trivial typos in comments

[Randy Dunlap]

On 10/17/13 18:12, Xie XiuQi wrote:
> Signed-off-by: Xie XiuQi 
> ---
>  kernel/irq/chip.c   |2 +-
>  kernel/irq/manage.c |2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
> index a3bb14f..dc04c16 100644
> --- a/kernel/irq/chip.c
> +++ b/kernel/irq/chip.c
> @@ -214,7 +214,7 @@ void irq_enable(struct irq_desc *desc)
>  }
> 
>  /**
> - * irq_disable - Mark interupt disabled
> + * irq_disable - Mark interrupt disabled
>   * @desc:irq descriptor which should be disabled
>   *
>   * If the chip does not implement the irq_disable callback, we
> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
> index 514bcfd..6394a3c 100644
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -786,7 +786,7 @@ irq_forced_thread_fn(struct irq_desc *desc, struct 
> irqaction *action)
>  }
> 
>  /*
> - * Interrupts explicitely requested as threaded interupts want to be
> + * Interrupts explicitely requested as threaded interrupts want to be

 explicitly

>   * preemtible - many of them need to sleep and wait for slow busses to
>   * complete.
>   */
> 


-- 
~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] of/lib: Export fdt routines to modules

[Michael Bohan]

On Thu, Oct 17, 2013 at 05:44:07PM -0700, Guenter Roeck wrote:
> On 10/17/2013 04:51 PM, Michael Bohan wrote:
> >On Wed, Oct 16, 2013 at 09:54:27PM -0700, Guenter Roeck wrote:
> >>Still, what prevents you from unflattening it and just using the
> >>normal device tree functions as David suggested ?
> >
> >I'm assuming you're suggesting to use of_fdt_unflatten_tree()?
> 
> Yes, that was the idea.
> 
> >That's an interesting thought. I was planning to scan the fdt
> >only once and populate my own structures, but I suppose I could
> >use the of_* APIs equivalently.
> >
> >It seems there are some problems though.  of_fdt_unflatten_tree()
> >does not return errors, and so for the purposes of my driver it
> >would not be sufficient to detect an invalid firmware image.
> >
> It does so, at least partially. If there is an error, it won't set
> the nodes pointer. Granted, that is not perfect, but it is at least
> a start. Ultimately, I considered it 'good enough' for my purpose
> (for devicetree overlays - see [1] below), as any missing mandatory
> properties or nodes are detected later when trying to actually read
> the properties. In my case, I also have a couple of validation
> properties to ensure that the overlay is acceptable (specifically
> I use 'compatible' and 'assembly-ids', but that is really a detail).

That's certainly better than nothing, but I think it would be
useful to make a distinction between a malformed fdt and a fdt
that's simply missing the right information. Without error
codes, I think we lose this aspect.

> >Would people entertain changing this API
> >(and implicitly __unflatten_device_tree) to return errors? I'm
> >guessing the reason it's coded that way is because the normal
> >usecase is 'system boot', at which time errors aren't that
> >meaningful.
> >
> >Also, there's no way to free the memory that was allocated from
> >the unflatten process. May I add one?
> >
> 
> The patchset submitted by Pantelis Antoniou to add support for
> devicetree overlays adds this and other related functionality.
> See [1], specifically the patch titled "OF: Introduce utility
> helper functions". Not sure where that is going, though.
> It may need some cleanup to be accepted upstream.
> Copying Pantelis for comments.
> Guenter
> 
> [1] https://lkml.org/lkml/2013/1/4/276

Thanks. So it seems that Pantelis's __of_free_tree() is what I'm
looking for.

Mike

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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] tracing: fix referencing after memory freeing and refactors code

[Steven Rostedt]

On Thu, 17 Oct 2013 22:44:56 -0300
"Geyslan G. Bem"  wrote:

> Restructures function logic conditions testing 'tracing_open_generic'
> return before the others. It avoids: unnecessary trace_array_get and
> kzalloc when tracing is disabled; and fix the possible 'dir'
> assignment after freeing it.
> 
> Centralizes the exiting, ensuring the 'trace_array_put' on error,
> in accordance to Coding Style, Chapter 7.
> 
> Signed-off-by: Geyslan G. Bem 
> ---
>  kernel/trace/trace_events.c | 22 --
>  1 file changed, 12 insertions(+), 10 deletions(-)
> 
> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> index 368a4d5..8232362 100644
> --- a/kernel/trace/trace_events.c
> +++ b/kernel/trace/trace_events.c
> @@ -1108,26 +1108,28 @@ static int system_tr_open(struct inode *inode, struct 
> file *filp)
>   struct trace_array *tr = inode->i_private;
>   int ret;
>  
> - if (trace_array_get(tr) < 0)
> - return -ENODEV;
> + ret = tracing_open_generic(inode, filp);
> + if (ret)
> + return ret;
> +
> + ret = trace_array_get(tr);
> + if (ret)
> + return ret;

Hmm,

I'm thinking of just nuking the tracing_open_generic() here. The only
thing it does here is the tracing_disabled check. The assignment of
inode->i_private to filp->private_data is pointless as it just
reassigns it anyway.

We could add a tracing_is_disabled() function to test instead.

-- Steve

>  
>   /* Make a temporary dir that has no system but points to tr */
>   dir = kzalloc(sizeof(*dir), GFP_KERNEL);
>   if (!dir) {
> - trace_array_put(tr);
> - return -ENOMEM;
> + ret = -ENOMEM;
> + goto err_dir;
>   }
>  
>   dir->tr = tr;
>  
> - ret = tracing_open_generic(inode, filp);
> - if (ret < 0) {
> - trace_array_put(tr);
> - kfree(dir);
> - }
> -
>   filp->private_data = dir;
> + return 0;
>  
> +err_dir:
> + trace_array_put(tr);
>   return ret;
>  }
>  

--
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 4/5] trace-cmd: Add virt-server mode for a virtualization environment

[Steven Rostedt]

On Fri, 13 Sep 2013 11:06:37 +0900
Yoshihiro YUNOMAE  wrote:

>  static int *create_all_readers(int cpus, const char *node, const char *port,
> -int pagesize, int fd)
> +const char *domain, int virtpid, int pagesize, 
> int fd)
>  {
>   char buf[BUFSIZ];
> - int *port_array;
> + int *port_array = NULL;
>   int *pid_array;
>   int start_port;
>   int udp_port;
>   int cpu;
>   int pid;
>  
> - port_array = malloc_or_die(sizeof(int) * cpus);
> + if (node) {
> + port_array = malloc_or_die(sizeof(int) * cpus);
> + start_port = START_PORT_SEARCH;
> + }
>   pid_array = malloc_or_die(sizeof(int) * cpus);
>   memset(pid_array, 0, sizeof(int) * cpus);
>  
> - start_port = START_PORT_SEARCH;
> -
> - /* Now create a UDP port for each CPU */
> + /* Now create a reader for each CPU */
>   for (cpu = 0; cpu < cpus; cpu++) {
> - udp_port = open_udp(node, port, , cpu,
> - pagesize, start_port);
> - if (udp_port < 0)
> - goto out_free;
> - port_array[cpu] = udp_port;
> + if (node) {
> + udp_port = open_udp(node, port, , cpu,
> + pagesize, start_port);
> + if (udp_port < 0)
> + goto out_free;
> + port_array[cpu] = udp_port;
> + /*
> +  * due to some bugging finding ports,

s/due/Due/

> +  * force search after last port
> +  */
> + start_port = udp_port + 1;
> + } else {
> + if (open_virtio_serial_pipe(, cpu, pagesize,
> + domain, virtpid) < 0)
> + goto out_free;
> + }
>   pid_array[cpu] = pid;
>   /*
>* Due to some bugging finding ports,

Hmm, it seems that you added the start_port = udp_port + 1 above, but
shouldn't you remove the one here?

> @@ -482,7 +595,7 @@ static int *create_all_readers(int cpus, const char 
> *node, const char *port,
>   return pid_array;
>  
>   out_free:
> - destroy_all_readers(cpus, pid_array, node, port);
> + destroy_all_readers(cpus, pid_array, node, port, domain, virtpid);
>   return NULL;
>  }
>  
> @@ -524,7 +637,7 @@ static void stop_all_readers(int cpus, int *pid_array)
>  }
>  
>  static void put_together_file(int cpus, int ofd, const char *node,
> -   const char *port)
> +   const char *port, const char *domain, int virtpid)
>  {
>   char **temp_files;
>   int cpu;
> @@ -533,25 +646,31 @@ static void put_together_file(int cpus, int ofd, const 
> char *node,
>   temp_files = malloc_or_die(sizeof(*temp_files) * cpus);
>  
>   for (cpu = 0; cpu < cpus; cpu++)
> - temp_files[cpu] = get_temp_file(node, port, cpu);
> + temp_files[cpu] = get_temp_file(node, port, domain,
> + virtpid, cpu);
>  
>   tracecmd_attach_cpu_data_fd(ofd, cpus, temp_files);
>   free(temp_files);
>  }
>  
> -static void process_client(const char *node, const char *port, int fd)
> +static void process_client(const char *node, const char *port,
> +const char *domain, int virtpid, int fd)
>  {
>   int *pid_array;
>   int pagesize;
>   int cpus;
>   int ofd;
>  
> - if (communicate_with_client(fd, , ) < 0)
> - return;
> -
> - ofd = create_client_file(node, port);
> + if (node) {
> + if (communicate_with_client_nw(fd, , ) < 0)

I take it _nw is for "network". If so, please use "*_net" instead. "nw"
is pretty meaningless.

This applies for all functions.

-- Steve

> + return;
> + } else {
> + if (communicate_with_client_virt(fd, domain, , ) 
> < 0)
> + return;
> + }
>  
> - pid_array = create_all_readers(cpus, node, port, pagesize, fd);
> + ofd = create_client_file(node, port, domain, virtpid);
> + pid_array = create_all_readers(cpus, node, port, domain, virtpid, 
> pagesize, fd);
>   if (!pid_array)
>   return;
>  
> @@ -570,9 +689,22 @@ static void process_client(const char *node, const char 
> *port, int fd)
>   /* wait a little to have the readers clean up */
>   sleep(1);
>  
> - put_together_file(cpus, ofd, node, port);
> + put_together_file(cpus, ofd, node, port, domain, virtpid);
>  
> - destroy_all_readers(cpus, pid_array, node, port);
> + destroy_all_readers(cpus, pid_array, node, port, domain, virtpid);
> +}
> +
> +static void process_client_nw(const char *node, const char *port, int fd)
> +{
> + process_client(node, port, NULL, 0, fd);
> +}
> +
> 

Re: [PATCH] LSM: ModPin LSM for module loading restrictions

[Casey Schaufler]

On 10/16/2013 3:43 PM, Kees Cook wrote:
> On Wed, Oct 16, 2013 at 2:42 PM, Casey Schaufler  
> wrote:
>> On 10/16/2013 1:47 PM, Tetsuo Handa wrote:
>>> Kees Cook wrote:
 Any update on this? It'd be nice to have it in linux-next.
>>> What was the conclusion at LSS about multiple concurrent LSM support?
>>> If we agreed to merge multiple concurrent LSM support, there will be 
>>> nothing to
>>> prevent this module from merging.
>>>
>> Yeah.
> The discussion at LSS basically centered around the catch-22 of not
> being able to stack, and not having anything to stack (since Yama got
> an hard-coded exception). So I sent this LSM as one I'd been waiting
> for stacking on. Essentially, I'm breaking the catch-22 by sending
> this. I'd like it to get into the tree so we don't have a catch-22
> about stacking any more. :)
>
>> The conclusion was that it needs to be staged because it's
>> too much to swallow all at once. I can see that. It's going
>> to be a lot of work to rearrange and rebase. That's a chunk
>> of time I don't expect to have for a while. It looks good
>> to happen, but don't hold supper for me.
> Do you want me to take a stab at it? It sounds like it was desirable
> to cut the current series into two halves? The core changes first, and
> the userspace interface changes next?

My read on it was a three phased approach:

First, move the cap "module" checks out of the other modules
and directly into security.c. There would be no "default" module.
If another module is loaded, call the hook it defines if the cap
check passes. Add /sys/kernel/security/lsm to make it easy to
find out what module (if any) is active.

Second, allow more than one LSM to get called if so requested.
Call them all, and return the error code of the last failure.
Refuse to load more than one module that uses an exclusive feature;
netlabel, secmark or XFRM.

Finally, put in all the gimmicks to decide who gets which of the
networking facilities.

Yes, If you've got the cycles to work with it I'd be happy for the help.


>
> -Kees
>

--
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 2/5] trace-cmd: Apply the trace-msg protocol for communication between a server and clients

[Steven Rostedt]

On Fri, 13 Sep 2013 11:06:32 +0900
Yoshihiro YUNOMAE  wrote:


> diff --git a/trace-msg.c b/trace-msg.c
> new file mode 100644
> index 000..cf82ff6
> --- /dev/null
> +++ b/trace-msg.c
> @@ -0,0 +1,683 @@
> +/*
> + * trace-msg.c : define message protocol for communication between clients 
> and
> + *   a server
> + *
> + * Copyright (C) 2013 Hitachi, Ltd.
> + * Created by Yoshihiro YUNOMAE 
> + *
> + * ~~
> + *
> + * 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; version 2 of the License (not later!)
> + *

BTW, as this can be used in a library, would be OK with re-licensing
this as the LGPL v2.1?

I try to keep all the helper C files as LGPL and the program files as
GPL. I would have made all of trace-cmd LGPL, but there was some code I
needed that was GPL, and I could only use it if I had the program as
GPL code.

-- Steve


> + * 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,  see 
> + *
> + * ~~
> + */
> +
--
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] tracing: fix referencing after memory freeing and refactors code

[Geyslan G. Bem]

Restructures function logic conditions testing 'tracing_open_generic'
return before the others. It avoids: unnecessary trace_array_get and
kzalloc when tracing is disabled; and fix the possible 'dir'
assignment after freeing it.

Centralizes the exiting, ensuring the 'trace_array_put' on error,
in accordance to Coding Style, Chapter 7.

Signed-off-by: Geyslan G. Bem 
---
 kernel/trace/trace_events.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 368a4d5..8232362 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -1108,26 +1108,28 @@ static int system_tr_open(struct inode *inode, struct 
file *filp)
struct trace_array *tr = inode->i_private;
int ret;
 
-   if (trace_array_get(tr) < 0)
-   return -ENODEV;
+   ret = tracing_open_generic(inode, filp);
+   if (ret)
+   return ret;
+
+   ret = trace_array_get(tr);
+   if (ret)
+   return ret;
 
/* Make a temporary dir that has no system but points to tr */
dir = kzalloc(sizeof(*dir), GFP_KERNEL);
if (!dir) {
-   trace_array_put(tr);
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto err_dir;
}
 
dir->tr = tr;
 
-   ret = tracing_open_generic(inode, filp);
-   if (ret < 0) {
-   trace_array_put(tr);
-   kfree(dir);
-   }
-
filp->private_data = dir;
+   return 0;
 
+err_dir:
+   trace_array_put(tr);
return ret;
 }
 
-- 
1.8.4

--
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 report about ipt_do_table( )

[Wang, Yalin]

hi   Will

yes, of course .

by the way, could you send me your delivered commit link after you submit ?

Thanks

-Original Message-
From: Will Deacon [mailto:will.dea...@arm.com] 
Sent: Thursday, October 17, 2013 6:41 PM
To: Wang, Yalin
Cc: 'linux-arm-msm-ow...@vger.kernel.org'; 'linux-kernel@vger.kernel.org'; 
Peng, Arthur; Zhang, Bojie; Gu, Youcai 1 (EXT); Alevoor, Raghavendra 2
Subject: Re: BUG report about ipt_do_table( )

On Thu, Oct 17, 2013 at 02:51:34AM +0100, Wang, Yalin wrote:
> Hi  Will,

Hello,

> I am happy to notify that our stability test has passed, And this 
> Crash don't happen again, So seems this patch work now .

Great!

> We has merged it into our release SW .
> Could I know if this patch will be delivered into kernel Mainline by 
> you ?

Sure, can I add your tested-by please?

Will
--
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 net V2 1/2] virtio-net: don't respond to cpu hotplug notifier if we're not ready

[Rusty Russell]

"Michael S. Tsirkin"  writes:
> On Thu, Oct 17, 2013 at 09:57:41AM +1030, Rusty Russell wrote:
>> Jason Wang  writes:
>> > We're trying to re-configure the affinity unconditionally in cpu hotplug
>> > callback. This may lead the issue during resuming from s3/s4 since
>> >
>> > - virt queues haven't been allocated at that time.
>> > - it's unnecessary since thaw method will re-configure the affinity.
>> >
>> > Fix this issue by checking the config_enable and do nothing is we're not 
>> > ready.
>> >
>> > The bug were introduced by commit 8de4b2f3ae90c8fc0f17eeaab87d5a951b66ee17
>> > (virtio-net: reset virtqueue affinity when doing cpu hotplug).
>> >
>> > Cc: Rusty Russell 
>> > Cc: Michael S. Tsirkin 
>> > Cc: Wanlong Gao 
>> > Acked-by: Michael S. Tsirkin 
>> > Reviewed-by: Wanlong Gao 
>> > Signed-off-by: Jason Wang 
>> > ---
>> > The patch is need for 3.8 and above.
>> 
>> Please put 'CC: sta...@kernel.org # 3.8+' in the commit.
>
> Not if this is going in through the net tree.

WTF?  Wow, there really *is* an FAQ: https://lwn.net/Articles/561669/

DaveM is the best maintainer I've ever known, but I abhor the idea that
every subsystem has its own incompatible variant on workflow and style.

Asking people to express 'CC: stable' in words is error-prone; if Dave
wants to filter it, he's quite capable.

Rusty.
--
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] n_gsm: race between ld close and gsmtty open

[channing]

On Thu, 2013-10-17 at 10:14 -0700, Greg KH wrote:
> On Thu, Oct 17, 2013 at 11:29:10AM +0800, channing wrote:
> > 
> > ttyA has ld associated to n_gsm, when ttyA is closing, it triggers
> > to release gsmttyB's ld data dlci[B], then race would happen if gsmttyB
> > is opening in parallel.
> > 
> > Here are some of race cases we found recently in test:
> 
> Are these still an issue with 3.12-rc4?  Lots of pty rework has gone
> into there that should help to resolve some of these problems.
> 

Hi Greg,
I viewed 3.12-rc4 and IMHO it still has this issue, Please correct me if I'm 
wrong.
This patch was based on 3.12-rc4, following is version info of my code base:

linux/Makefile:
VERSION = 3
PATCHLEVEL = 12
SUBLEVEL = 0
EXTRAVERSION = -rc4

And this version of patch has one line not correct, I updated it in another 
mail 
with title "[PATCH v2]n_gsm:...", would you please check?

thanks a lot,
chao

--
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.8.y.z extended stable ] Linux 3.8.13.11 stable review

[Ben Hutchings]

On Thu, 2013-10-10 at 11:37 -0600, Bjorn Helgaas wrote:
> On Thu, Oct 10, 2013 at 9:40 AM, Kamal Mostafa  wrote:
> > This is the start of the review cycle for the Linux 3.8.13.11 stable kernel.
> 
> Would anybody be interested in adding some sort of "stable" tag to the
> subject lines of stable backport patches, e.g.,  instead of:
> 
>   [PATCH 001/104] htb: fix sign extension bug
> 
> something like:
> 
>   [STABLE 3.8.13.11 001/104] htb: fix sign extension bug
> 
> I don't mind having the stable patches on LKML, but it would be nice
> if it were easier to distinguish stable backports from new patches.  I
> know the patches are nicely threaded behind this message, but some
> readers don't really pay attention to that.

I agree that some distinction is needed, but I'm not convinced about
that precise format.  I don't think it's worth including version
components after the stable base version e.g. 3.2.  And I think that
including the version is a big enough clue that this is for a stable
branch and not mainline.

So I've changed my review script to put a subject prefix of 'PATCH 3.2'
before the patch number (and similarly in the cover letter).  But if
there's consensus that a more explicit tag is wanted then I'll follow
that.

Ben.

-- 
Ben Hutchings
Horngren's Observation:
   Among economists, the real world is often a special case.


signature.asc
Description: This is a digitally signed message part

Re: [PATCH 4/6] rcusync: Introduce struct rcu_sync_ops

[Lai Jiangshan]

On 10/17/2013 11:42 PM, Paul E. McKenney wrote:
> On Thu, Oct 17, 2013 at 10:07:15AM +0800, Lai Jiangshan wrote:
>> On 10/08/2013 06:25 PM, Peter Zijlstra wrote:
>>> From: Oleg Nesterov 
>>>
>>> Add the new struct rcu_sync_ops which holds sync/call methods, and
>>> turn the function pointers in rcu_sync_struct into an array of struct
>>> rcu_sync_ops.
>>
>> Hi, Paul
>>
>> I think this work should be done in rcupdate.[ch] side by introducing
>> struct rcu_flavor.
> 
> I -do- have on my list to add an rcutorture test for rcu_sync, but
> what do you have in mind by adding struct rcu_flavor?  I am guessing
> that you do not mean to try to create an rcu_state and a set of

No.
The thing what I need is just as same as Oleg Nesterov implemented.
It is just a structure with several function pointers for different RCU 
variants.
But it would be better if we implement in rcupdate.[ch],
and name it to struct rcu_flavor like the URCU.

After we have struct rcu_flavor, we can replace the following code
to a pointer to struct rcu_flavor.

struct rcu_state:
void (*call)(struct rcu_head *head, /* call_rcu() flavor. */
 void (*func)(struct rcu_head *head));

struct rcu_torture_ops {
int (*readlock)(void);
void (*readunlock)(int idx);
void (*sync)(void);
void (*exp_sync)(void);
void (*call)(struct rcu_head *head, void (*func)(struct rcu_head *rcu));
void (*cb_barrier)(void);
};

and struct rcu_sync {
...
};


Thanks,
Lai.



> rcu_data structures for rcu_sync -- the write-side optimizations
> would not fit well into rcu_state/rcu_data.
> 
> You might mean to simply put this code into rcupdate.[ch], which
> would be OK, but rcu_sync seems to me to be sufficiently different
> to deserve its own .c and .h files.
> 
> So what did you have in mind?

I mean we need something like struct rcu_flavor as the URCU.


> 
>   Thanx, Paul
> 
>> Thanks,
>> Lai
>>
>>>
>>> This simplifies the "init" helpers, and this way it is simpler to add
>>> the new methods we need, especially ifdef'ed.
>>>
>>> Signed-off-by: Peter Zijlstra 
>>> Link: http://lkml.kernel.org/r/20131005171746.ga17...@redhat.com
>>> ---
>>>
>>> diff --git a/include/linux/rcusync.h b/include/linux/rcusync.h
>>> index 7858491..988ec33 100644
>>> --- a/include/linux/rcusync.h
>>> +++ b/include/linux/rcusync.h
>>> @@ -4,6 +4,8 @@
>>>  #include 
>>>  #include 
>>>  
>>> +enum rcu_sync_type { RCU_SYNC, RCU_SCHED_SYNC, RCU_BH_SYNC };
>>> +
>>>  struct rcu_sync_struct {
>>> int gp_state;
>>> int gp_count;
>>> @@ -12,53 +14,37 @@ struct rcu_sync_struct {
>>> int cb_state;
>>> struct rcu_head cb_head;
>>>  
>>> -   void (*sync)(void);
>>> -   void (*call)(struct rcu_head *, void (*)(struct rcu_head *));
>>> +   enum rcu_sync_type  gp_type;
>>>  };
>>>  
>>> -#define ___RCU_SYNC_INIT(name) 
>>> \
>>> -   .gp_state = 0,  \
>>> -   .gp_count = 0,  \
>>> -   .gp_wait = __WAIT_QUEUE_HEAD_INITIALIZER(name.gp_wait), \
>>> -   .cb_state = 0
>>> -
>>> -#define __RCU_SCHED_SYNC_INIT(name) {  
>>> \
>>> -   ___RCU_SYNC_INIT(name), \
>>> -   .sync = synchronize_sched,  \
>>> -   .call = call_rcu_sched, \
>>> -}
>>> -
>>> -#define __RCU_BH_SYNC_INIT(name) { \
>>> -   ___RCU_SYNC_INIT(name), \
>>> -   .sync = synchronize_rcu_bh, \
>>> -   .call = call_rcu_bh,\
>>> -}
>>> -
>>> -#define __RCU_SYNC_INIT(name) {
>>> \
>>> -   ___RCU_SYNC_INIT(name), \
>>> -   .sync = synchronize_rcu,\
>>> -   .call = call_rcu,   \
>>> -}
>>> -
>>> -#define DEFINE_RCU_SCHED_SYNC(name)
>>> \
>>> -   struct rcu_sync_struct name = __RCU_SCHED_SYNC_INIT(name)
>>> -
>>> -#define DEFINE_RCU_BH_SYNC(name)   \
>>> -   struct rcu_sync_struct name = __RCU_BH_SYNC_INIT(name)
>>> -
>>> -#define DEFINE_RCU_SYNC(name)  
>>> \
>>> -   struct rcu_sync_struct name = __RCU_SYNC_INIT(name)
>>> -
>>>  static inline bool rcu_sync_is_idle(struct rcu_sync_struct *rss)
>>>  {
>>> return !rss->gp_state; /* GP_IDLE */
>>>  }
>>>  
>>> -enum rcu_sync_type { RCU_SYNC, RCU_SCHED_SYNC, RCU_BH_SYNC };
>>> -
>>>  extern void rcu_sync_init(struct rcu_sync_struct *, enum rcu_sync_type);
>>>  extern 

Re: [PATCH 3/3] vdso: preallocate new vmas

[Linus Torvalds]

This seems somewhat insane:

   int install_special_mapping(struct mm_struct *mm,
  unsigned long addr, unsigned long len,
  +   unsigned long vm_flags, struct page **pages,
  +   struct vm_area_struct **vma_prealloc)
   {
  +   int ret = 0;
  +   struct vm_area_struct *vma = *vma_prealloc;

(removed the "old" lines to make it more readable).

Why pass in "struct vm_area_struct **vma_prealloc" when you could just
pass in a plain and more readable "struct vm_area_struct *vma"?

My *guess* is that you originally cleared the vma_prealloc thing if
you used it, but in the patch you sent out you definitely don't (the
_only_ use of that "vma_prealloc" is the line that loads the content
into "vma", so this interface looks like it is some remnant of an
earlier and more complicated patch?

Linus
--
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 net-next v3 3/9] static_key: WARN on usage before jump_label_init was called

[Hannes Frederic Sowa]

On Fri, Oct 18, 2013 at 02:50:57AM +0200, Andi Kleen wrote:
> On Thu, Oct 17, 2013 at 05:19:40PM -0400, Steven Rostedt wrote:
> > On Thu, 17 Oct 2013 07:31:57 +0200
> > Hannes Frederic Sowa  wrote:
> > 
> > > Based on a patch from Andi Kleen.
> > 
> > I'm fine with the patch, but the change log needs a lot more work.
> > Like, why is this needed?  I know, but does anyone else?
> 
> Or just merge the orininal patch. While being less verbose
> in the warning it had a full changelog.

I don't care that much which patch gets merged but I just want to
point out another difference: I added WARN_ONs on code paths without
architecture support for static_keys to help developers on platforms
without support for that.

Greetings,

  Hannes

--
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 3/3] timekeeping: Fix some trivial typos in comments

[Xie XiuQi]

Signed-off-by: Xie XiuQi 
---
 kernel/time/timekeeping.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 947ba25..3abf534 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1613,9 +1613,10 @@ void get_xtime_and_monotonic_and_sleep_offset(struct 
timespec *xtim,
  * ktime_get_update_offsets - hrtimer helper
  * @offs_real: pointer to storage for monotonic -> realtime offset
  * @offs_boot: pointer to storage for monotonic -> boottime offset
+ * @offs_tai:  pointer to storage for monotonic -> clock tai offset
  *
  * Returns current monotonic time and updates the offsets
- * Called from hrtimer_interupt() or retrigger_next_event()
+ * Called from hrtimer_interrupt() or retrigger_next_event()
  */
 ktime_t ktime_get_update_offsets(ktime_t *offs_real, ktime_t *offs_boot,
ktime_t *offs_tai)
-- 
1.7.7



--
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 2/3] mm: Fix some trivial typos in comments

[Xie XiuQi]

Signed-off-by: Xie XiuQi 
---
 mm/slub.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/mm/slub.c b/mm/slub.c
index c3eb3d3..c9aa8d4 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -955,7 +955,7 @@ static inline void slab_free_hook(struct kmem_cache *s, 
void *x)
kmemleak_free_recursive(x, s->flags);

/*
-* Trouble is that we may no longer disable interupts in the fast path
+* Trouble is that we may no longer disable interrupts in the fast path
 * So in order to make the debug calls that expect irqs to be
 * disabled we need to disable interrupts temporarily.
 */
-- 
1.7.7



--
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] alarmtimer: return EINVAL instead of ENOTSUPP if rtcdev doesn't exist

[KOSAKI Motohiro]

(10/17/13 1:05 PM), John Stultz wrote:

On 10/14/2013 02:33 PM, kosaki.motoh...@gmail.com wrote:

From: KOSAKI Motohiro 

Fedora Ruby maintainer reported latest Ruby doesn't work on Fedora Rawhide
on ARM. (http://bugs.ruby-lang.org/issues/9008)

Because of, commit 1c6b39ad3f (alarmtimers: Return -ENOTSUPP if no
RTC device is present) intruduced to return ENOTSUPP when
clock_get{time,res} can't find a RTC device. However it is incorrect.

Posix and Linux man pages agree that clock_gettime and clock_getres
should return EINVAL if clk_id argument is invalid. This is significant
different from timer_create API.

This patch fixes it.


Hrm... So I feel like there is a difference here. The clockid for
CLOCK_BOOTTIME_ALARM and CLOCK_REALTIME_ALARM are both valid.

Its just that they're not supported on this specific hardware because it
apparently lacks a RTC that has told the system it can be used as a
wakeup device (Its actually quite likely on the hardware that the RTC
can be a wakeup device, but that the driver is probably setting the
wakeup flag after the RTC registered - so there is probably a driver bug
here too).

So I feel like in this case EINVAL isn't quite right.  I'll admit it is
somewhat new behavior, because we haven't had any clockids before that
were dependent on the particular hardware, they either existed in a
kernel verison or didn't.

Would updating the manpage be a better route?


Nope.

ENOTSUPP is not exported to userland. ENOTSUP (single P) and EOPNOTSUP is
valid errno (and they are same on linux), but ENOTSUPP is a kernel internal 
specific.

Moreover, I completely disagree your position. Both CLOCK_REALTIME_ALARM 
unsupported
kernel and ARM which doesn't support RTC should use the same error because 
application
need the same fallback.



--
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/3] irq: Fix some trivial typos in comments

[Xie XiuQi]

Signed-off-by: Xie XiuQi 
---
 kernel/irq/chip.c   |2 +-
 kernel/irq/manage.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index a3bb14f..dc04c16 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -214,7 +214,7 @@ void irq_enable(struct irq_desc *desc)
 }

 /**
- * irq_disable - Mark interupt disabled
+ * irq_disable - Mark interrupt disabled
  * @desc:  irq descriptor which should be disabled
  *
  * If the chip does not implement the irq_disable callback, we
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 514bcfd..6394a3c 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -786,7 +786,7 @@ irq_forced_thread_fn(struct irq_desc *desc, struct 
irqaction *action)
 }

 /*
- * Interrupts explicitely requested as threaded interupts want to be
+ * Interrupts explicitely requested as threaded interrupts want to be
  * preemtible - many of them need to sleep and wait for slow busses to
  * complete.
  */
-- 
1.7.7



--
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/3] Fix some trivial typos in comments

[Xie XiuQi]

Correct some spelling typo in comments

Xie XiuQi (3):
  irq: fix some trivial typos in comments
  mm: fix some trivial typos in comments
  timekeeping: Fix some trivial typos in comments.

 kernel/irq/chip.c |2 +-
 kernel/irq/manage.c   |2 +-
 kernel/time/timekeeping.c |3 ++-
 mm/slub.c |2 +-
 4 files changed, 5 insertions(+), 4 deletions(-)

-- 
1.7.7


--
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] usb: usb_phy_gen: refine conditional declaration of usb_nop_xceiv_register

[Josh Boyer]

On Thu, Oct 17, 2013 at 01:31:47PM -0700, Guenter Roeck wrote:
> On Thu, Oct 17, 2013 at 01:25:48PM -0400, Josh Boyer wrote:
> > On Wed, Oct 16, 2013 at 07:18:41PM -0700, Guenter Roeck wrote:
> > > Commit 3fa4d734 (usb: phy: rename nop_usb_xceiv => usb_phy_gen_xceiv)
> > > changed the conditional around the declaration of usb_nop_xceiv_register
> > > from
> > >   #if defined(CONFIG_NOP_USB_XCEIV) ||
> > >   (defined(CONFIG_NOP_USB_XCEIV_MODULE) && defined(MODULE))
> > > to
> > >   #if IS_ENABLED(CONFIG_NOP_USB_XCEIV)
> > > 
> > > While that looks the same, it is semantically different. The first 
> > > expression
> > > is true if CONFIG_NOP_USB_XCEIV is built as module and if the including
> > > code is built as module. The second expression is true if code depending 
> > > on
> > > CONFIG_NOP_USB_XCEIV if built as module or into the kernel.
> > > 
> > > As a result, the arm:allmodconfig build fails with
> > > 
> > > arch/arm/mach-omap2/built-in.o: In function `omap3_evm_init':
> > > arch/arm/mach-omap2/board-omap3evm.c:703: undefined reference to
> > >   `usb_nop_xceiv_register'
> > > 
> > > Fix the problem by reverting to the old conditional.
> > > 
> > > Cc: Josh Boyer 
> > > Signed-off-by: Guenter Roeck 
> > 
> > I'm not entirely sure why I was CC'd on this one, but the patch looks
> > good to me.  I do wonder how many other uses of IS_ENABLED aren't taking
> > this into account though.
> > 
> Unless I am wrong, you submitted a different patch to fix the same problem,
> which went nowhere, so I figured it was appropriate to Cc: you on this one.
> If not, my apologies.

Ah, so I did!  Amazing what I can forget in a month.

> As for other use cases of IS_ENABLED, agreed, that may be an ongoing concern. 
> That will have to be addressed individually, though.

Yep.

josh
--
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 net-next v3 3/9] static_key: WARN on usage before jump_label_init was called

[Andi Kleen]

On Thu, Oct 17, 2013 at 05:19:40PM -0400, Steven Rostedt wrote:
> On Thu, 17 Oct 2013 07:31:57 +0200
> Hannes Frederic Sowa  wrote:
> 
> > Based on a patch from Andi Kleen.
> 
> I'm fine with the patch, but the change log needs a lot more work.
> Like, why is this needed?  I know, but does anyone else?

Or just merge the orininal patch. While being less verbose
in the warning it had a full changelog.

-Andi
--
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 3/3] vdso: preallocate new vmas

[Davidlohr Bueso]

With the exception of um and tile, architectures that use
the install_special_mapping() function, when setting up a
new vma at program startup, do so with the mmap_sem lock
held for writing. Unless there's an error, this process
ends up allocating a new vma through kmem_cache_zalloc,
and inserting it in the task's address space.

This patch moves the vma's space allocation outside of
install_special_mapping(), and leaves the callers to do so 
explicitly, without depending on mmap_sem. The same goes for 
freeing: if the new vma isn't used (and thus the process fails 
at some point), it's caller's responsibility to free it - 
currently this is done inside install_special_mapping.

Furthermore, uprobes behaves exactly the same and thus now the
xol_add_vma() function also preallocates the new vma.

While the changes to x86 vdso handling have been tested on both
large and small 64-bit systems, the rest of the architectures
are totally *untested*. Note that all changes are quite similar
from architecture to architecture.

This patch, when tested on a 64core, 256 Gb NUMA server, benefited
several aim7 workloads: long +27% throughput with over 1500 users;
compute +6.5% with over 1000 users; fserver +83% for small amounts
of users (10-100 range) and +9% for more and new_fserver, showing
a similar behavior, got +67% boost with 100 users and an avg of +8%
when more users were added.

Signed-off-by: Davidlohr Bueso 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Richard Kuo 
Cc: Ralf Baechle 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: Paul Mundt 
Cc: Chris Metcalf 
Cc: Jeff Dike 
Cc: Richard Weinberger 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Peter Zijlstra 
---
 arch/arm/kernel/process.c  | 22 --
 arch/arm64/kernel/vdso.c   | 21 +
 arch/hexagon/kernel/vdso.c | 16 
 arch/mips/kernel/vdso.c| 10 +-
 arch/powerpc/kernel/vdso.c | 11 ---
 arch/s390/kernel/vdso.c| 19 +++
 arch/sh/kernel/vsyscall/vsyscall.c | 11 ++-
 arch/tile/kernel/vdso.c| 13 ++---
 arch/um/kernel/skas/mmu.c  | 16 +++-
 arch/unicore32/kernel/process.c| 17 -
 arch/x86/um/vdso/vma.c | 18 ++
 arch/x86/vdso/vdso32-setup.c   | 16 +++-
 arch/x86/vdso/vma.c| 10 +-
 include/linux/mm.h |  3 ++-
 kernel/events/uprobes.c| 14 --
 mm/mmap.c  | 18 +++---
 16 files changed, 179 insertions(+), 56 deletions(-)

diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 94f6b05..5637c92 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -480,6 +481,7 @@ extern struct page *get_signal_page(void);
 int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 {
struct mm_struct *mm = current->mm;
+   struct vm_area_struct *vma;
unsigned long addr;
int ret;
 
@@ -488,6 +490,10 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, 
int uses_interp)
if (!signal_page)
return -ENOMEM;
 
+   vma = kmem_cache_zalloc(vm_area_cachep, GFP_KERNEL);
+   if (unlikely(!vma))
+   return -ENOMEM;
+
down_write(>mmap_sem);
addr = get_unmapped_area(NULL, 0, PAGE_SIZE, 0, 0);
if (IS_ERR_VALUE(addr)) {
@@ -496,14 +502,18 @@ int arch_setup_additional_pages(struct linux_binprm 
*bprm, int uses_interp)
}
 
ret = install_special_mapping(mm, addr, PAGE_SIZE,
-   VM_READ | VM_EXEC | VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC,
-   _page);
-
-   if (ret == 0)
-   mm->context.sigpage = addr;
+ VM_READ | VM_EXEC | VM_MAYREAD |
+ VM_MAYWRITE | VM_MAYEXEC,
+ _page, );
+   if (ret)
+   goto up_fail;
 
- up_fail:
+   mm->context.sigpage = addr;
+   up_write(>mmap_sem);
+   return 0;
+up_fail:
up_write(>mmap_sem);
+   kmem_cache_free(vm_area_cachep, vma);
return ret;
 }
 #endif
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 6a389dc..519a44c 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -83,20 +83,26 @@ arch_initcall(alloc_vectors_page);
 
 int aarch32_setup_vectors_page(struct linux_binprm *bprm, int uses_interp)
 {
+   struct vm_area_struct *vma;
struct mm_struct *mm = current->mm;
unsigned long addr = AARCH32_VECTORS_BASE;
int ret;
 
+   vma = kmem_cache_zalloc(vm_area_cachep, GFP_KERNEL);
+   if (unlikely(!vma))
+   return 

[PATCH 0/3] mm,vdso: preallocate new vmas

[Davidlohr Bueso]

Linus recently pointed out[1] some of the amount of unnecessary work 
being done with the mmap_sem held. This patchset is a very initial 
approach on reducing some of the contention on this lock, and moving
work outside of the critical region.

Patch 1 adds a simple helper function.

Patch 2 moves out some trivial setup logic in mlock related calls.

Patch 3 allows managing new vmas without requiring the mmap_sem for
vdsos. While it's true that there are many other scenarios where
this can be done, few are actually as straightforward as this in the
sense that we *always* end up allocating memory anyways, so there's really
no tradeoffs. For this reason I wanted to get this patch out in the open.

There are a few points to consider when preallocating vmas at the start
of system calls, such as how many new vmas (ie: callers of split_vma can
end up calling twice, depending on the mm state at that point) or the 
probability
that we end up merging the vma instead of having to create a new one, like the 
case of brk or copy_vma. In both cases the overhead of creating and freeing
memory at every syscall's invocation might outweigh what we gain in not holding
the sem.

[1] https://lkml.org/lkml/2013/10/9/665 

Thanks!

Davidlohr Bueso (3):
  mm: add mlock_future_check helper
  mm/mlock: prepare params outside critical region
  vdso: preallocate new vmas

 arch/arm/kernel/process.c  | 22 +
 arch/arm64/kernel/vdso.c   | 21 ++---
 arch/hexagon/kernel/vdso.c | 16 +++---
 arch/mips/kernel/vdso.c| 10 +-
 arch/powerpc/kernel/vdso.c | 11 +--
 arch/s390/kernel/vdso.c| 19 +---
 arch/sh/kernel/vsyscall/vsyscall.c | 11 ++-
 arch/tile/kernel/vdso.c| 13 ++--
 arch/um/kernel/skas/mmu.c  | 16 +++---
 arch/unicore32/kernel/process.c| 17 +++---
 arch/x86/um/vdso/vma.c | 18 ---
 arch/x86/vdso/vdso32-setup.c   | 16 +-
 arch/x86/vdso/vma.c| 10 +-
 include/linux/mm.h |  3 +-
 kernel/events/uprobes.c| 14 +++--
 mm/mlock.c | 18 ++-
 mm/mmap.c  | 63 ++
 17 files changed, 213 insertions(+), 85 deletions(-)

-- 
1.8.1.4

--
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/3] mm: add mlock_future_check helper

[Davidlohr Bueso]

Both do_brk and do_mmap_pgoff verify that we actually
capable of locking future pages if the corresponding
VM_LOCKED flags are used. Encapsulate this logic into
a single mlock_future_check() helper function.

Signed-off-by: Davidlohr Bueso 
Cc: Rik van Riel 
Cc: Michel Lespinasse 
---
 mm/mmap.c | 45 +++--
 1 file changed, 23 insertions(+), 22 deletions(-)

diff --git a/mm/mmap.c b/mm/mmap.c
index 9d54851..6a7824d 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1192,6 +1192,24 @@ static inline unsigned long round_hint_to_min(unsigned 
long hint)
return hint;
 }
 
+static inline int mlock_future_check(struct mm_struct *mm,
+unsigned long flags,
+unsigned long len)
+{
+   unsigned long locked, lock_limit;
+
+   /*  mlock MCL_FUTURE? */
+   if (flags & VM_LOCKED) {
+   locked = len >> PAGE_SHIFT;
+   locked += mm->locked_vm;
+   lock_limit = rlimit(RLIMIT_MEMLOCK);
+   lock_limit >>= PAGE_SHIFT;
+   if (locked > lock_limit && !capable(CAP_IPC_LOCK))
+   return -EAGAIN;
+   }
+   return 0;
+}
+
 /*
  * The caller must hold down_write(>mm->mmap_sem).
  */
@@ -1253,16 +1271,8 @@ unsigned long do_mmap_pgoff(struct file *file, unsigned 
long addr,
if (!can_do_mlock())
return -EPERM;
 
-   /* mlock MCL_FUTURE? */
-   if (vm_flags & VM_LOCKED) {
-   unsigned long locked, lock_limit;
-   locked = len >> PAGE_SHIFT;
-   locked += mm->locked_vm;
-   lock_limit = rlimit(RLIMIT_MEMLOCK);
-   lock_limit >>= PAGE_SHIFT;
-   if (locked > lock_limit && !capable(CAP_IPC_LOCK))
-   return -EAGAIN;
-   }
+   if (mlock_future_check(mm, vm_flags, len))
+   return -EAGAIN;
 
if (file) {
struct inode *inode = file_inode(file);
@@ -2593,18 +2603,9 @@ static unsigned long do_brk(unsigned long addr, unsigned 
long len)
if (error & ~PAGE_MASK)
return error;
 
-   /*
-* mlock MCL_FUTURE?
-*/
-   if (mm->def_flags & VM_LOCKED) {
-   unsigned long locked, lock_limit;
-   locked = len >> PAGE_SHIFT;
-   locked += mm->locked_vm;
-   lock_limit = rlimit(RLIMIT_MEMLOCK);
-   lock_limit >>= PAGE_SHIFT;
-   if (locked > lock_limit && !capable(CAP_IPC_LOCK))
-   return -EAGAIN;
-   }
+   error = mlock_future_check(mm, mm->def_flags, len);
+   if (error)
+   return error;
 
/*
 * mm->mmap_sem is required to protect against another thread
-- 
1.8.1.4

--
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 2/3] mm/mlock: prepare params outside critical region

[Davidlohr Bueso]

All mlock related syscalls prepare lock limits, lengths and
start parameters with the mmap_sem held. Move this logic
outside of the critical region. For the case of mlock, continue
incrementing the amount already locked by mm->locked_vm with
the rwsem taken.

Signed-off-by: Davidlohr Bueso 
Cc: Michel Lespinasse 
Cc: Vlastimil Babka 
---
 mm/mlock.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/mm/mlock.c b/mm/mlock.c
index d480cd6..aa7de13 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -689,19 +689,21 @@ SYSCALL_DEFINE2(mlock, unsigned long, start, size_t, len)
 
lru_add_drain_all();/* flush pagevec */
 
-   down_write(>mm->mmap_sem);
len = PAGE_ALIGN(len + (start & ~PAGE_MASK));
start &= PAGE_MASK;
 
-   locked = len >> PAGE_SHIFT;
-   locked += current->mm->locked_vm;
-
lock_limit = rlimit(RLIMIT_MEMLOCK);
lock_limit >>= PAGE_SHIFT;
+   locked = len >> PAGE_SHIFT;
+
+   down_write(>mm->mmap_sem);
+
+   locked += current->mm->locked_vm;
 
/* check against resource limits */
if ((locked <= lock_limit) || capable(CAP_IPC_LOCK))
error = do_mlock(start, len, 1);
+
up_write(>mm->mmap_sem);
if (!error)
error = __mm_populate(start, len, 0);
@@ -712,11 +714,13 @@ SYSCALL_DEFINE2(munlock, unsigned long, start, size_t, 
len)
 {
int ret;
 
-   down_write(>mm->mmap_sem);
len = PAGE_ALIGN(len + (start & ~PAGE_MASK));
start &= PAGE_MASK;
+
+   down_write(>mm->mmap_sem);
ret = do_mlock(start, len, 0);
up_write(>mm->mmap_sem);
+
return ret;
 }
 
@@ -761,12 +765,12 @@ SYSCALL_DEFINE1(mlockall, int, flags)
if (flags & MCL_CURRENT)
lru_add_drain_all();/* flush pagevec */
 
-   down_write(>mm->mmap_sem);
-
lock_limit = rlimit(RLIMIT_MEMLOCK);
lock_limit >>= PAGE_SHIFT;
 
ret = -ENOMEM;
+   down_write(>mm->mmap_sem);
+
if (!(flags & MCL_CURRENT) || (current->mm->total_vm <= lock_limit) ||
capable(CAP_IPC_LOCK))
ret = do_mlockall(flags);
-- 
1.8.1.4

--
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] of/lib: Export fdt routines to modules

[Guenter Roeck]

On 10/17/2013 04:51 PM, Michael Bohan wrote:

On Wed, Oct 16, 2013 at 09:54:27PM -0700, Guenter Roeck wrote:

On 10/16/2013 05:27 PM, Michael Bohan wrote:

My motivation is actually to use the fdt format as a firmware.
I have a requirement to express driver metadata that's loadable

>from the filesystem. This data is not reasonable to place in the

system Device Tree, since it's application specific and does not
actually describe hardware. The fact that the format chosen is
'flattened device tree' is merely just a coincidence.


Still, what prevents you from unflattening it and just using the
normal device tree functions as David suggested ?


I'm assuming you're suggesting to use of_fdt_unflatten_tree()?


Yes, that was the idea.


That's an interesting thought. I was planning to scan the fdt
only once and populate my own structures, but I suppose I could
use the of_* APIs equivalently.

It seems there are some problems though.  of_fdt_unflatten_tree()
does not return errors, and so for the purposes of my driver it
would not be sufficient to detect an invalid firmware image.


It does so, at least partially. If there is an error, it won't set
the nodes pointer. Granted, that is not perfect, but it is at least
a start. Ultimately, I considered it 'good enough' for my purpose
(for devicetree overlays - see [1] below), as any missing mandatory
properties or nodes are detected later when trying to actually read
the properties. In my case, I also have a couple of validation
properties to ensure that the overlay is acceptable (specifically
I use 'compatible' and 'assembly-ids', but that is really a detail).


Would people entertain changing this API
(and implicitly __unflatten_device_tree) to return errors? I'm
guessing the reason it's coded that way is because the normal
usecase is 'system boot', at which time errors aren't that
meaningful.

Also, there's no way to free the memory that was allocated from
the unflatten process. May I add one?



The patchset submitted by Pantelis Antoniou to add support for
devicetree overlays adds this and other related functionality.
See [1], specifically the patch titled "OF: Introduce utility
helper functions". Not sure where that is going, though.
It may need some cleanup to be accepted upstream.
Copying Pantelis for comments.

I also updated the devicetree discussion list address to get comments
from the experts.

Thanks,
Guenter

[1] https://lkml.org/lkml/2013/1/4/276

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

linux-next: Tree for Oct 17

[Mark Brown]

Hi all,

I've uploaded today's linux-next tree to the master branch of the
repository below:

git://gitorious.org/thierryreding/linux-next.git

A next-20131017 tag is also provided for convenience.

One new conflict today but otherwise uneventful.  x86_64 allmodconfigs
build after each merge but no other build tests were done.


signature.asc
Description: Digital signature

[tip:x86/intel-mid] mrst: Fixed printk/pr_* related issues

[tip-bot for Kuppuswamy Sathyanarayanan]

Commit-ID:  001d4c7aea587ce0865c07ec45aa56ecbefd431a
Gitweb: http://git.kernel.org/tip/001d4c7aea587ce0865c07ec45aa56ecbefd431a
Author: Kuppuswamy Sathyanarayanan 

AuthorDate: Thu, 17 Oct 2013 15:35:25 -0700
Committer:  H. Peter Anvin 
CommitDate: Thu, 17 Oct 2013 16:40:33 -0700

mrst: Fixed printk/pr_* related issues

Fixed printk and pr_* related issues in mrst related files.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Link: 
http://lkml.kernel.org/r/1382049336-21316-2-git-send-email-david.a.co...@linux.intel.com
Signed-off-by: David Cohen 
Signed-off-by: H. Peter Anvin 
---
 arch/x86/platform/mrst/early_printk_mrst.c | 2 +-
 arch/x86/platform/mrst/mrst.c  | 2 +-
 arch/x86/platform/mrst/vrtc.c  | 5 ++---
 3 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/arch/x86/platform/mrst/early_printk_mrst.c 
b/arch/x86/platform/mrst/early_printk_mrst.c
index 028454f..95880f7 100644
--- a/arch/x86/platform/mrst/early_printk_mrst.c
+++ b/arch/x86/platform/mrst/early_printk_mrst.c
@@ -213,7 +213,7 @@ static void early_mrst_spi_putc(char c)
}
 
if (!timeout)
-   pr_warning("MRST earlycon: timed out\n");
+   pr_warn("MRST earlycon: timed out\n");
else
max3110_write_data(c);
 }
diff --git a/arch/x86/platform/mrst/mrst.c b/arch/x86/platform/mrst/mrst.c
index 3ca5957..b9aeb54 100644
--- a/arch/x86/platform/mrst/mrst.c
+++ b/arch/x86/platform/mrst/mrst.c
@@ -328,7 +328,7 @@ static inline int __init setup_x86_mrst_timer(char *arg)
else if (strcmp("lapic_and_apbt", arg) == 0)
mrst_timer_options = MRST_TIMER_LAPIC_APBT;
else {
-   pr_warning("X86 MRST timer option %s not recognised"
+   pr_warn("X86 MRST timer option %s not recognised"
   " use x86_mrst_timer=apbt_only or lapic_and_apbt\n",
   arg);
return -EINVAL;
diff --git a/arch/x86/platform/mrst/vrtc.c b/arch/x86/platform/mrst/vrtc.c
index 5e355b1..ca4f7d9 100644
--- a/arch/x86/platform/mrst/vrtc.c
+++ b/arch/x86/platform/mrst/vrtc.c
@@ -79,7 +79,7 @@ void vrtc_get_time(struct timespec *now)
/* vRTC YEAR reg contains the offset to 1972 */
year += 1972;
 
-   printk(KERN_INFO "vRTC: sec: %d min: %d hour: %d day: %d "
+   pr_info("vRTC: sec: %d min: %d hour: %d day: %d "
"mon: %d year: %d\n", sec, min, hour, mday, mon, year);
 
now->tv_sec = mktime(year, mon, mday, hour, min, sec);
@@ -109,8 +109,7 @@ int vrtc_set_mmss(const struct timespec *now)
vrtc_cmos_write(tm.tm_sec, RTC_SECONDS);
spin_unlock_irqrestore(_lock, flags);
} else {
-   printk(KERN_ERR
-  "%s: Invalid vRTC value: write of %lx to vRTC failed\n",
+   pr_err("%s: Invalid vRTC value: write of %lx to vRTC failed\n",
__FUNCTION__, now->tv_sec);
retval = -EINVAL;
}
--
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/

[tip:x86/intel-mid] intel_mid: Move platform device setups to their own platform_.* files

[tip-bot for David Cohen]

Commit-ID:  40a96d54ee2232045783e657eb9224cd723dcb40
Gitweb: http://git.kernel.org/tip/40a96d54ee2232045783e657eb9224cd723dcb40
Author: David Cohen 
AuthorDate: Thu, 17 Oct 2013 15:35:36 -0700
Committer:  H. Peter Anvin 
CommitDate: Thu, 17 Oct 2013 16:41:50 -0700

intel_mid: Move platform device setups to their own platform_.* files

As Intel rolling out more SoC's after Moorestown, we need to
re-structure the code in a way that is backward compatible and easy to
expand. This patch implements a flexible way to support multiple boards
and devices.

This patch does not add any new functional support. It just refactors
the existing code to increase the modularity and decrease the code
duplication for supporting multiple soc's and boards.

Currently intel-mid.c has both board and soc related code in one file.
This patch moves the board related code to new files and let linker
script to create SFI devite table following this:

1. Move the SFI device specific code to
   arch/x86/platform/intel-mid/device-libs/platform_.*
   A new device file is added for every supported device. This code will
   get conditionally compiled by using corresponding device driver
   CONFIG option.

2. Move the device_ids location to .x86_intel_mid_dev.init section by
   using new sfi_device() macro.

This patch was based on previous code from Sathyanarayanan Kuppuswamy.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Link: 
http://lkml.kernel.org/r/1382049336-21316-13-git-send-email-david.a.co...@linux.intel.com
Signed-off-by: David Cohen 
Signed-off-by: H. Peter Anvin 
---
 arch/x86/include/asm/intel-mid.h   |  16 +
 arch/x86/platform/intel-mid/Makefile   |   8 +-
 arch/x86/platform/intel-mid/device_libs/Makefile   |  22 ++
 .../intel-mid/device_libs/platform_bma023.c|  20 +
 .../intel-mid/device_libs/platform_emc1403.c   |  41 ++
 .../intel-mid/device_libs/platform_gpio_keys.c |  83 
 .../platform/intel-mid/device_libs/platform_ipc.c  |  68 
 .../platform/intel-mid/device_libs/platform_ipc.h  |  17 +
 .../intel-mid/device_libs/platform_lis331.c|  39 ++
 .../intel-mid/device_libs/platform_max3111.c   |  35 ++
 .../intel-mid/device_libs/platform_max7315.c   |  79 
 .../intel-mid/device_libs/platform_mpu3050.c   |  36 ++
 .../platform/intel-mid/device_libs/platform_msic.c |  87 +
 .../platform/intel-mid/device_libs/platform_msic.h |  19 +
 .../intel-mid/device_libs/platform_msic_audio.c|  47 +++
 .../intel-mid/device_libs/platform_msic_battery.c  |  37 ++
 .../intel-mid/device_libs/platform_msic_gpio.c |  48 +++
 .../intel-mid/device_libs/platform_msic_ocd.c  |  49 +++
 .../device_libs/platform_msic_power_btn.c  |  36 ++
 .../intel-mid/device_libs/platform_msic_thermal.c  |  37 ++
 .../intel-mid/device_libs/platform_pmic_gpio.c |  54 +++
 .../intel-mid/device_libs/platform_tc35876x.c  |  36 ++
 .../intel-mid/device_libs/platform_tca6416.c   |  57 +++
 arch/x86/platform/intel-mid/intel-mid.c| 419 -
 arch/x86/platform/intel-mid/sfi.c  |  14 +-
 include/linux/sfi.h|   3 +
 26 files changed, 978 insertions(+), 429 deletions(-)

diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index 3b0e7a7..459769d 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -12,8 +12,11 @@
 #define _ASM_X86_INTEL_MID_H
 
 #include 
+#include 
 
 extern int intel_mid_pci_init(void);
+extern int get_gpio_by_name(const char *name);
+extern void intel_scu_device_register(struct platform_device *pdev);
 extern int __init sfi_parse_mrtc(struct sfi_table_header *table);
 extern int __init sfi_parse_mtmr(struct sfi_table_header *table);
 extern int sfi_mrtc_num;
@@ -34,6 +37,10 @@ struct devs_id {
struct devs_id *dev);
 };
 
+#define sfi_device(i)   \
+   static const struct devs_id *const __intel_mid_sfi_##i##_dev __used \
+   __attribute__((__section__(".x86_intel_mid_dev.init"))) = 
+
 /*
  * Medfield is the follow-up of Moorestown, it combines two chip solution into
  * one. Other than that it also added always-on and constant tsc and lapic
@@ -55,9 +62,15 @@ static inline enum intel_mid_cpu_type 
intel_mid_identify_cpu(void)
return __intel_mid_cpu_chip;
 }
 
+static inline bool intel_mid_has_msic(void)
+{
+   return (intel_mid_identify_cpu() == INTEL_MID_CPU_CHIP_PENWELL);
+}
+
 #else /* !CONFIG_X86_INTEL_MID */
 
 #define intel_mid_identify_cpu()(0)
+#define intel_mid_has_msic()(0)
 
 #endif /* !CONFIG_X86_INTEL_MID */
 
@@ -94,4 +107,7 @@ extern void intel_scu_devices_destroy(void);
 
 extern void intel_mid_rtc_init(void);
 
+/* the offset for the mapping of global gpio pin to irq */
+#define INTEL_MID_IRQ_OFFSET 0x100
+
 #endif /* _ASM_X86_INTEL_MID_H */
diff --git a/arch/x86/platform/intel-mid/Makefile 
b/arch/x86/platform/intel-mid/Makefile

[tip:x86/intel-mid] x86: intel-mid: Add section for sfi device table

[tip-bot for David Cohen]

Commit-ID:  66ac50137049b3d3fab39e5ae245e1562aee5acd
Gitweb: http://git.kernel.org/tip/66ac50137049b3d3fab39e5ae245e1562aee5acd
Author: David Cohen 
AuthorDate: Thu, 17 Oct 2013 15:35:35 -0700
Committer:  H. Peter Anvin 
CommitDate: Thu, 17 Oct 2013 16:41:04 -0700

x86: intel-mid: Add section for sfi device table

When Intel mid uses SFI table to enumerate devices, it requires an extra
device table with further information about how to probe such devices.

This patch creates a section where the device table will stay if
CONFIG_X86_INTEL_MID is selected.

Signed-off-by: David Cohen 
Link: 
http://lkml.kernel.org/r/1382049336-21316-12-git-send-email-david.a.co...@linux.intel.com
Signed-off-by: H. Peter Anvin 
---
 arch/x86/kernel/vmlinux.lds.S | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 10c4f30..da6b35a 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -199,6 +199,15 @@ SECTIONS
__x86_cpu_dev_end = .;
}
 
+#ifdef CONFIG_X86_INTEL_MID
+   .x86_intel_mid_dev.init : AT(ADDR(.x86_intel_mid_dev.init) - \
+   LOAD_OFFSET) {
+   __x86_intel_mid_dev_start = .;
+   *(.x86_intel_mid_dev.init)
+   __x86_intel_mid_dev_end = .;
+   }
+#endif
+
/*
 * start address and size of operations which during runtime
 * can be patched with virtualization friendly instructions or
--
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/

[tip:x86/intel-mid] intel_mid: Added custom handler for ipc devices

[tip-bot for Kuppuswamy Sathyanarayanan]

Commit-ID:  49c72a0a8ad640fa6026962056eeaf85a4ce79fd
Gitweb: http://git.kernel.org/tip/49c72a0a8ad640fa6026962056eeaf85a4ce79fd
Author: Kuppuswamy Sathyanarayanan 

AuthorDate: Thu, 17 Oct 2013 15:35:32 -0700
Committer:  H. Peter Anvin 
CommitDate: Thu, 17 Oct 2013 16:40:50 -0700

intel_mid: Added custom handler for ipc devices

Added a custom handler for medfield based ipc devices and
moved devs_id structure defintion to header file.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Link: 
http://lkml.kernel.org/r/1382049336-21316-9-git-send-email-david.a.co...@linux.intel.com
Signed-off-by: David Cohen 
Signed-off-by: H. Peter Anvin 
---
 arch/x86/include/asm/intel-mid.h| 15 ++
 arch/x86/platform/intel-mid/intel-mid.c | 82 -
 2 files changed, 66 insertions(+), 31 deletions(-)

diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index beb7a5f..ad236ae 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -19,6 +19,21 @@ extern int sfi_mrtc_num;
 extern struct sfi_rtc_table_entry sfi_mrtc_array[];
 
 /*
+ * Here defines the array of devices platform data that IAFW would export
+ * through SFI "DEVS" table, we use name and type to match the device and
+ * its platform data.
+ */
+struct devs_id {
+   char name[SFI_NAME_LEN + 1];
+   u8 type;
+   u8 delay;
+   void *(*get_platform_data)(void *info);
+   /* Custom handler for devices */
+   void (*device_handler)(struct sfi_device_table_entry *pentry,
+   struct devs_id *dev);
+};
+
+/*
  * Medfield is the follow-up of Moorestown, it combines two chip solution into
  * one. Other than that it also added always-on and constant tsc and lapic
  * timers. Medfield is the platform name, and the chip name is called Penwell
diff --git a/arch/x86/platform/intel-mid/intel-mid.c 
b/arch/x86/platform/intel-mid/intel-mid.c
index 7bfd784..40a3ff8 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -78,6 +78,8 @@ int sfi_mtimer_num;
 struct sfi_rtc_table_entry sfi_mrtc_array[SFI_MRTC_MAX];
 EXPORT_SYMBOL_GPL(sfi_mrtc_array);
 int sfi_mrtc_num;
+static void __init ipc_device_handler(struct sfi_device_table_entry *pentry,
+   struct devs_id *dev);
 
 static void intel_mid_power_off(void)
 {
@@ -386,21 +388,6 @@ static int get_gpio_by_name(const char *name)
return -1;
 }
 
-/*
- * Here defines the array of devices platform data that IAFW would export
- * through SFI "DEVS" table, we use name and type to match the device and
- * its platform data.
- */
-struct devs_id {
-   char name[SFI_NAME_LEN + 1];
-   u8 type;
-   u8 delay;
-   void *(*get_platform_data)(void *info);
-   /* Custom handler for devices */
-   void (*device_handler)(struct sfi_device_table_entry *pentry,
-   struct devs_id *dev);
-};
-
 /* the offset for the mapping of global gpio pin to irq */
 #define INTEL_MID_IRQ_OFFSET 0x100
 
@@ -695,24 +682,24 @@ static void *tc35876x_platform_data(void *data)
 static const struct devs_id __initconst device_ids[] = {
{"bma023", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"pmic_gpio", SFI_DEV_TYPE_SPI, 1, _gpio_platform_data, NULL},
-   {"pmic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data, NULL},
+   {"pmic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data, 
_device_handler},
{"spi_max3111", SFI_DEV_TYPE_SPI, 0, _platform_data, NULL},
{"i2c_max7315", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"i2c_max7315_2", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"tca6416", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"emc1403", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"i2c_accel", SFI_DEV_TYPE_I2C, 0, _platform_data, NULL},
-   {"pmic_audio", SFI_DEV_TYPE_IPC, 1, _platform_data, NULL},
+   {"pmic_audio", SFI_DEV_TYPE_IPC, 1, _platform_data, 
_device_handler},
{"mpu3050", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"i2c_disp_brig", SFI_DEV_TYPE_I2C, 0, _platform_data, NULL},
 
/* MSIC subdevices */
-   {"msic_battery", SFI_DEV_TYPE_IPC, 1, _battery_platform_data, 
NULL},
-   {"msic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data, NULL},
-   {"msic_audio", SFI_DEV_TYPE_IPC, 1, _audio_platform_data, NULL},
-   {"msic_power_btn", SFI_DEV_TYPE_IPC, 1, _power_btn_platform_data, 
NULL},
-   {"msic_ocd", SFI_DEV_TYPE_IPC, 1, _ocd_platform_data, NULL},
-   {"msic_thermal", SFI_DEV_TYPE_IPC, 1, _thermal_platform_data, 
NULL},
+   {"msic_battery", SFI_DEV_TYPE_IPC, 1, _battery_platform_data, 
_device_handler},
+   {"msic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data, 
_device_handler},
+   {"msic_audio", SFI_DEV_TYPE_IPC, 1, _audio_platform_data, 
_device_handler},
+   {"msic_power_btn", SFI_DEV_TYPE_IPC, 1, _power_btn_platform_data, 

[tip:x86/intel-mid] intel-mid: sfi: Allow struct devs_id.get_platform_data to be NULL

[tip-bot for David Cohen]

Commit-ID:  0e6fdb5f036338bc38bf660c65c931b3e92a31d7
Gitweb: http://git.kernel.org/tip/0e6fdb5f036338bc38bf660c65c931b3e92a31d7
Author: David Cohen 
AuthorDate: Thu, 17 Oct 2013 15:35:34 -0700
Committer:  H. Peter Anvin 
CommitDate: Thu, 17 Oct 2013 16:40:59 -0700

intel-mid: sfi: Allow struct devs_id.get_platform_data to be NULL

Intel mid sfi code doesn't need struct devs_id.get_platform_data != NULL.
If the callback is not set, just assume there is no platform_data.

Signed-off-by: David Cohen 
Link: 
http://lkml.kernel.org/r/1382049336-21316-11-git-send-email-david.a.co...@linux.intel.com
Cc: Kuppuswamy Sathyanarayanan 
Signed-off-by: H. Peter Anvin 
---
 arch/x86/platform/intel-mid/sfi.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/x86/platform/intel-mid/sfi.c 
b/arch/x86/platform/intel-mid/sfi.c
index 2f8196d..3f1c171 100644
--- a/arch/x86/platform/intel-mid/sfi.c
+++ b/arch/x86/platform/intel-mid/sfi.c
@@ -70,6 +70,9 @@ struct blocking_notifier_head intel_scu_notifier =
BLOCKING_NOTIFIER_INIT(intel_scu_notifier);
 EXPORT_SYMBOL_GPL(intel_scu_notifier);
 
+#define intel_mid_sfi_get_pdata(dev, priv) \
+   ((dev)->get_platform_data ? (dev)->get_platform_data(priv) : NULL)
+
 /* parse all the mtimer info to a static mtimer array */
 int __init sfi_parse_mtmr(struct sfi_table_header *table)
 {
@@ -334,7 +337,7 @@ static void __init sfi_handle_ipc_dev(struct 
sfi_device_table_entry *pentry,
 
pr_debug("IPC bus, name = %16.16s, irq = 0x%2x\n",
pentry->name, pentry->irq);
-   pdata = dev->get_platform_data(pentry);
+   pdata = intel_mid_sfi_get_pdata(dev, pentry);
 
pdev = platform_device_alloc(pentry->name, 0);
if (pdev == NULL) {
@@ -367,7 +370,7 @@ static void __init sfi_handle_spi_dev(struct 
sfi_device_table_entry *pentry,
spi_info.max_speed_hz,
spi_info.chip_select);
 
-   pdata = dev->get_platform_data(_info);
+   pdata = intel_mid_sfi_get_pdata(dev, _info);
 
spi_info.platform_data = pdata;
if (dev->delay)
@@ -391,7 +394,7 @@ static void __init sfi_handle_i2c_dev(struct 
sfi_device_table_entry *pentry,
i2c_info.type,
i2c_info.irq,
i2c_info.addr);
-   pdata = dev->get_platform_data(_info);
+   pdata = intel_mid_sfi_get_pdata(dev, _info);
i2c_info.platform_data = pdata;
 
if (dev->delay)
@@ -450,7 +453,7 @@ static int __init sfi_parse_devs(struct sfi_table_header 
*table)
 
dev = get_device_id(pentry->type, pentry->name);
 
-   if ((dev == NULL) || (dev->get_platform_data == NULL))
+   if (!dev)
continue;
 
if (dev->device_handler) {
--
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/

[tip:x86/intel-mid] intel_mid: Moved SFI related code to sfi.c

[tip-bot for Kuppuswamy Sathyanarayanan]

Commit-ID:  aeedb370e7398fb5b39185b295d36f2da0653215
Gitweb: http://git.kernel.org/tip/aeedb370e7398fb5b39185b295d36f2da0653215
Author: Kuppuswamy Sathyanarayanan 

AuthorDate: Thu, 17 Oct 2013 15:35:33 -0700
Committer:  H. Peter Anvin 
CommitDate: Thu, 17 Oct 2013 16:40:51 -0700

intel_mid: Moved SFI related code to sfi.c

Moved SFI specific parsing/handling code to sfi.c. This will enable us
to reuse our intel-mid code for platforms that supports firmware
interfaces other than SFI (like ACPI).

Signed-off-by: Kuppuswamy Sathyanarayanan 

Link: 
http://lkml.kernel.org/r/1382049336-21316-10-git-send-email-david.a.co...@linux.intel.com
Signed-off-by: David Cohen 
Signed-off-by: H. Peter Anvin 
---
 arch/x86/include/asm/intel-mid.h|   1 +
 arch/x86/platform/intel-mid/Makefile|   2 +
 arch/x86/platform/intel-mid/intel-mid.c | 451 +
 arch/x86/platform/intel-mid/sfi.c   | 485 
 4 files changed, 489 insertions(+), 450 deletions(-)

diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index ad236ae..3b0e7a7 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -15,6 +15,7 @@
 
 extern int intel_mid_pci_init(void);
 extern int __init sfi_parse_mrtc(struct sfi_table_header *table);
+extern int __init sfi_parse_mtmr(struct sfi_table_header *table);
 extern int sfi_mrtc_num;
 extern struct sfi_rtc_table_entry sfi_mrtc_array[];
 
diff --git a/arch/x86/platform/intel-mid/Makefile 
b/arch/x86/platform/intel-mid/Makefile
index de29635..b11e5b2 100644
--- a/arch/x86/platform/intel-mid/Makefile
+++ b/arch/x86/platform/intel-mid/Makefile
@@ -1,3 +1,5 @@
 obj-$(CONFIG_X86_INTEL_MID) += intel-mid.o
 obj-$(CONFIG_X86_INTEL_MID)+= intel_mid_vrtc.o
 obj-$(CONFIG_EARLY_PRINTK_INTEL_MID)   += early_printk_intel_mid.o
+# SFI specific code
+obj-$(CONFIG_SFI) += sfi.o
diff --git a/arch/x86/platform/intel-mid/intel-mid.c 
b/arch/x86/platform/intel-mid/intel-mid.c
index 40a3ff8..4091569 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -18,19 +18,9 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
 
 #include 
 #include 
@@ -68,19 +58,11 @@
 
 enum intel_mid_timer_options intel_mid_timer_options;
 
-static u32 sfi_mtimer_usage[SFI_MTMR_MAX_NUM];
-static struct sfi_timer_table_entry sfi_mtimer_array[SFI_MTMR_MAX_NUM];
 enum intel_mid_cpu_type __intel_mid_cpu_chip;
 EXPORT_SYMBOL_GPL(__intel_mid_cpu_chip);
 
-int sfi_mtimer_num;
-
-struct sfi_rtc_table_entry sfi_mrtc_array[SFI_MRTC_MAX];
-EXPORT_SYMBOL_GPL(sfi_mrtc_array);
-int sfi_mrtc_num;
 static void __init ipc_device_handler(struct sfi_device_table_entry *pentry,
struct devs_id *dev);
-
 static void intel_mid_power_off(void)
 {
 }
@@ -90,114 +72,6 @@ static void intel_mid_reboot(void)
intel_scu_ipc_simple_command(IPCMSG_COLD_BOOT, 0);
 }
 
-/* parse all the mtimer info to a static mtimer array */
-static int __init sfi_parse_mtmr(struct sfi_table_header *table)
-{
-   struct sfi_table_simple *sb;
-   struct sfi_timer_table_entry *pentry;
-   struct mpc_intsrc mp_irq;
-   int totallen;
-
-   sb = (struct sfi_table_simple *)table;
-   if (!sfi_mtimer_num) {
-   sfi_mtimer_num = SFI_GET_NUM_ENTRIES(sb,
-   struct sfi_timer_table_entry);
-   pentry = (struct sfi_timer_table_entry *) sb->pentry;
-   totallen = sfi_mtimer_num * sizeof(*pentry);
-   memcpy(sfi_mtimer_array, pentry, totallen);
-   }
-
-   pr_debug("SFI MTIMER info (num = %d):\n", sfi_mtimer_num);
-   pentry = sfi_mtimer_array;
-   for (totallen = 0; totallen < sfi_mtimer_num; totallen++, pentry++) {
-   pr_debug("timer[%d]: paddr = 0x%08x, freq = %dHz,"
-   " irq = %d\n", totallen, (u32)pentry->phys_addr,
-   pentry->freq_hz, pentry->irq);
-   if (!pentry->irq)
-   continue;
-   mp_irq.type = MP_INTSRC;
-   mp_irq.irqtype = mp_INT;
-/* triggering mode edge bit 2-3, active high polarity bit 0-1 */
-   mp_irq.irqflag = 5;
-   mp_irq.srcbus = MP_BUS_ISA;
-   mp_irq.srcbusirq = pentry->irq; /* IRQ */
-   mp_irq.dstapic = MP_APIC_ALL;
-   mp_irq.dstirq = pentry->irq;
-   mp_save_irq(_irq);
-   }
-
-   return 0;
-}
-
-struct sfi_timer_table_entry *sfi_get_mtmr(int hint)
-{
-   int i;
-   if (hint < sfi_mtimer_num) {
-   if (!sfi_mtimer_usage[hint]) {
-   pr_debug("hint taken for timer %d irq %d\n",
-   hint, 

[tip:x86/intel-mid] intel_mid: Renamed *mrst* to *intel_mid*

[tip-bot for Kuppuswamy Sathyanarayanan]

Commit-ID:  712b6aa8731a7e148298c58cea66a5209c659e3c
Gitweb: http://git.kernel.org/tip/712b6aa8731a7e148298c58cea66a5209c659e3c
Author: Kuppuswamy Sathyanarayanan 

AuthorDate: Thu, 17 Oct 2013 15:35:29 -0700
Committer:  H. Peter Anvin 
CommitDate: Thu, 17 Oct 2013 16:40:47 -0700

intel_mid: Renamed *mrst* to *intel_mid*

mrst is used as common name to represent all intel_mid type
soc's. But moorsetwon is just one of the intel_mid soc. So
renamed them to use intel_mid.

This patch mainly renames the variables and related
functions that uses *mrst* prefix with *intel_mid*.

To ensure that there are no functional changes, I have compared
the objdump of related files before and after rename and found
the only difference is symbol and name changes.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Link: 
http://lkml.kernel.org/r/1382049336-21316-6-git-send-email-david.a.co...@linux.intel.com
Signed-off-by: David Cohen 
Signed-off-by: H. Peter Anvin 
---
 Documentation/kernel-parameters.txt|   6 +-
 arch/x86/include/asm/intel-mid.h   |  26 ++---
 arch/x86/include/asm/setup.h   |   4 +-
 arch/x86/include/uapi/asm/bootparam.h  |   2 +-
 arch/x86/kernel/apb_timer.c|   8 +-
 arch/x86/kernel/head32.c   |   4 +-
 arch/x86/kernel/rtc.c  |   2 +-
 arch/x86/pci/intel_mid_pci.c   |  12 +--
 .../platform/intel-mid/early_printk_intel_mid.c|   2 +-
 arch/x86/platform/intel-mid/intel-mid.c| 109 ++---
 arch/x86/platform/intel-mid/intel_mid_vrtc.c   |   8 +-
 drivers/platform/x86/intel_scu_ipc.c   |   2 +-
 drivers/watchdog/intel_scu_watchdog.c  |   2 +-
 13 files changed, 93 insertions(+), 94 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index fcbb736..dfaeb0c 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3471,11 +3471,11 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
default x2apic cluster mode on platforms
supporting x2apic.
 
-   x86_mrst_timer= [X86-32,APBT]
-   Choose timer option for x86 Moorestown MID platform.
+   x86_intel_mid_timer= [X86-32,APBT]
+   Choose timer option for x86 Intel MID platform.
Two valid options are apbt timer only and lapic timer
plus one apbt timer for broadcast timer.
-   x86_mrst_timer=apbt_only | lapic_and_apbt
+   x86_intel_mid_timer=apbt_only | lapic_and_apbt
 
xen_emul_unplug=[HW,X86,XEN]
Unplug Xen emulated devices
diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index cc79a4f..beb7a5f 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -13,7 +13,7 @@
 
 #include 
 
-extern int pci_mrst_init(void);
+extern int intel_mid_pci_init(void);
 extern int __init sfi_parse_mrtc(struct sfi_table_header *table);
 extern int sfi_mrtc_num;
 extern struct sfi_rtc_table_entry sfi_mrtc_array[];
@@ -25,33 +25,33 @@ extern struct sfi_rtc_table_entry sfi_mrtc_array[];
  * we treat Medfield/Penwell as a variant of Moorestown. Penwell can be
  * identified via MSRs.
  */
-enum mrst_cpu_type {
+enum intel_mid_cpu_type {
/* 1 was Moorestown */
-   MRST_CPU_CHIP_PENWELL = 2,
+   INTEL_MID_CPU_CHIP_PENWELL = 2,
 };
 
-extern enum mrst_cpu_type __mrst_cpu_chip;
+extern enum intel_mid_cpu_type __intel_mid_cpu_chip;
 
 #ifdef CONFIG_X86_INTEL_MID
 
-static inline enum mrst_cpu_type mrst_identify_cpu(void)
+static inline enum intel_mid_cpu_type intel_mid_identify_cpu(void)
 {
-   return __mrst_cpu_chip;
+   return __intel_mid_cpu_chip;
 }
 
 #else /* !CONFIG_X86_INTEL_MID */
 
-#define mrst_identify_cpu()(0)
+#define intel_mid_identify_cpu()(0)
 
 #endif /* !CONFIG_X86_INTEL_MID */
 
-enum mrst_timer_options {
-   MRST_TIMER_DEFAULT,
-   MRST_TIMER_APBT_ONLY,
-   MRST_TIMER_LAPIC_APBT,
+enum intel_mid_timer_options {
+   INTEL_MID_TIMER_DEFAULT,
+   INTEL_MID_TIMER_APBT_ONLY,
+   INTEL_MID_TIMER_LAPIC_APBT,
 };
 
-extern enum mrst_timer_options mrst_timer_options;
+extern enum intel_mid_timer_options intel_mid_timer_options;
 
 /*
  * Penwell uses spread spectrum clock, so the freq number is not exactly
@@ -76,6 +76,6 @@ extern void intel_scu_devices_destroy(void);
 #define MRST_VRTC_MAP_SZ   (1024)
 /*#define MRST_VRTC_PGOFFSET   (0xc00) */
 
-extern void mrst_rtc_init(void);
+extern void intel_mid_rtc_init(void);
 
 #endif /* _ASM_X86_INTEL_MID_H */
diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index 3475554..59bcf4e 100644
--- a/arch/x86/include/asm/setup.h
+++ 

[tip:x86/intel-mid] pci: intel_mid: Return true/ false in function returning bool

[tip-bot for Fengguang Wu]

Commit-ID:  6c21b176a93ffaa8023555107167379ccdc6b71f
Gitweb: http://git.kernel.org/tip/6c21b176a93ffaa8023555107167379ccdc6b71f
Author: Fengguang Wu 
AuthorDate: Thu, 17 Oct 2013 15:35:28 -0700
Committer:  H. Peter Anvin 
CommitDate: Thu, 17 Oct 2013 16:40:45 -0700

pci: intel_mid: Return true/false in function returning bool

Function 'type1_access_ok' should return bool value, not 0/1.
This patch changes 'return 0/1' to 'return false/true'.

Cc: Kuppuswamy Sathyanarayanan 
Cc: H. Peter Anvin 
Cc: David Cohen 
Signed-off-by: Fengguang Wu 
Link: 
http://lkml.kernel.org/r/1382049336-21316-5-git-send-email-david.a.co...@linux.intel.com
Signed-off-by: H. Peter Anvin 
---
 arch/x86/pci/intel_mid_pci.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
index f8715f7..c5ca5b9 100644
--- a/arch/x86/pci/intel_mid_pci.c
+++ b/arch/x86/pci/intel_mid_pci.c
@@ -150,12 +150,12 @@ static bool type1_access_ok(unsigned int bus, unsigned 
int devfn, int reg)
 * shim. Therefore, use the header type in shim instead.
 */
if (reg >= 0x100 || reg == PCI_STATUS || reg == PCI_HEADER_TYPE)
-   return 0;
+   return false;
if (bus == 0 && (devfn == PCI_DEVFN(2, 0)
|| devfn == PCI_DEVFN(0, 0)
|| devfn == PCI_DEVFN(3, 0)))
-   return 1;
-   return 0; /* Langwell on others */
+   return true;
+   return false; /* Langwell on others */
 }
 
 static int pci_read(struct pci_bus *bus, unsigned int devfn, int where,
--
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/

[tip:x86/intel-mid] intel_mid: Added custom device_handler support

[tip-bot for Kuppuswamy Sathyanarayanan]

Commit-ID:  3fd79ae4275001f293dbd170479e89df6c433226
Gitweb: http://git.kernel.org/tip/3fd79ae4275001f293dbd170479e89df6c433226
Author: Kuppuswamy Sathyanarayanan 

AuthorDate: Thu, 17 Oct 2013 15:35:31 -0700
Committer:  H. Peter Anvin 
CommitDate: Thu, 17 Oct 2013 16:40:49 -0700

intel_mid: Added custom device_handler support

This patch provides a means to add custom handler for
SFI devices. If you set device_handler as NULL in
device_id table standard SFI device handler will be used.
If its not NULL custom handler will be called.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Link: 
http://lkml.kernel.org/r/1382049336-21316-8-git-send-email-david.a.co...@linux.intel.com
Signed-off-by: David Cohen 
Signed-off-by: H. Peter Anvin 
---
 arch/x86/platform/intel-mid/intel-mid.c | 74 ++---
 1 file changed, 40 insertions(+), 34 deletions(-)

diff --git a/arch/x86/platform/intel-mid/intel-mid.c 
b/arch/x86/platform/intel-mid/intel-mid.c
index d24c729..7bfd784 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -396,6 +396,9 @@ struct devs_id {
u8 type;
u8 delay;
void *(*get_platform_data)(void *info);
+   /* Custom handler for devices */
+   void (*device_handler)(struct sfi_device_table_entry *pentry,
+   struct devs_id *dev);
 };
 
 /* the offset for the mapping of global gpio pin to irq */
@@ -690,28 +693,27 @@ static void *tc35876x_platform_data(void *data)
 }
 
 static const struct devs_id __initconst device_ids[] = {
-   {"bma023", SFI_DEV_TYPE_I2C, 1, _platform_data},
-   {"pmic_gpio", SFI_DEV_TYPE_SPI, 1, _gpio_platform_data},
-   {"pmic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data},
-   {"spi_max3111", SFI_DEV_TYPE_SPI, 0, _platform_data},
-   {"i2c_max7315", SFI_DEV_TYPE_I2C, 1, _platform_data},
-   {"i2c_max7315_2", SFI_DEV_TYPE_I2C, 1, _platform_data},
-   {"tca6416", SFI_DEV_TYPE_I2C, 1, _platform_data},
-   {"emc1403", SFI_DEV_TYPE_I2C, 1, _platform_data},
-   {"i2c_accel", SFI_DEV_TYPE_I2C, 0, _platform_data},
-   {"pmic_audio", SFI_DEV_TYPE_IPC, 1, _platform_data},
-   {"mpu3050", SFI_DEV_TYPE_I2C, 1, _platform_data},
-   {"i2c_disp_brig", SFI_DEV_TYPE_I2C, 0, _platform_data},
+   {"bma023", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
+   {"pmic_gpio", SFI_DEV_TYPE_SPI, 1, _gpio_platform_data, NULL},
+   {"pmic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data, NULL},
+   {"spi_max3111", SFI_DEV_TYPE_SPI, 0, _platform_data, NULL},
+   {"i2c_max7315", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
+   {"i2c_max7315_2", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
+   {"tca6416", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
+   {"emc1403", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
+   {"i2c_accel", SFI_DEV_TYPE_I2C, 0, _platform_data, NULL},
+   {"pmic_audio", SFI_DEV_TYPE_IPC, 1, _platform_data, NULL},
+   {"mpu3050", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
+   {"i2c_disp_brig", SFI_DEV_TYPE_I2C, 0, _platform_data, NULL},
 
/* MSIC subdevices */
-   {"msic_battery", SFI_DEV_TYPE_IPC, 1, _battery_platform_data},
-   {"msic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data},
-   {"msic_audio", SFI_DEV_TYPE_IPC, 1, _audio_platform_data},
-   {"msic_power_btn", SFI_DEV_TYPE_IPC, 1, _power_btn_platform_data},
-   {"msic_ocd", SFI_DEV_TYPE_IPC, 1, _ocd_platform_data},
-   {"msic_thermal", SFI_DEV_TYPE_IPC, 1, _thermal_platform_data},
-
-   {},
+   {"msic_battery", SFI_DEV_TYPE_IPC, 1, _battery_platform_data, 
NULL},
+   {"msic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data, NULL},
+   {"msic_audio", SFI_DEV_TYPE_IPC, 1, _audio_platform_data, NULL},
+   {"msic_power_btn", SFI_DEV_TYPE_IPC, 1, _power_btn_platform_data, 
NULL},
+   {"msic_ocd", SFI_DEV_TYPE_IPC, 1, _ocd_platform_data, NULL},
+   {"msic_thermal", SFI_DEV_TYPE_IPC, 1, _thermal_platform_data, 
NULL},
+   { 0 }
 };
 
 #define MAX_IPCDEVS24
@@ -965,20 +967,24 @@ static int __init sfi_parse_devs(struct sfi_table_header 
*table)
if ((dev == NULL) || (dev->get_platform_data == NULL))
continue;
 
-   switch (pentry->type) {
-   case SFI_DEV_TYPE_IPC:
-   sfi_handle_ipc_dev(pentry, dev);
-   break;
-   case SFI_DEV_TYPE_SPI:
-   sfi_handle_spi_dev(pentry, dev);
-   break;
-   case SFI_DEV_TYPE_I2C:
-   sfi_handle_i2c_dev(pentry, dev);
-   break;
-   case SFI_DEV_TYPE_UART:
-   case SFI_DEV_TYPE_HSI:
-   default:
-   ;
+   if (dev->device_handler) {
+   dev->device_handler(pentry, dev);
+   } else {
+   switch (pentry->type) 

[tip:x86/intel-mid] intel_mid: Refactored sfi_parse_devs() function

[tip-bot for Kuppuswamy Sathyanarayanan]

Commit-ID:  661b01076500e364c68dd9fdf0ef4216a75e8375
Gitweb: http://git.kernel.org/tip/661b01076500e364c68dd9fdf0ef4216a75e8375
Author: Kuppuswamy Sathyanarayanan 

AuthorDate: Thu, 17 Oct 2013 15:35:30 -0700
Committer:  H. Peter Anvin 
CommitDate: Thu, 17 Oct 2013 16:40:48 -0700

intel_mid: Refactored sfi_parse_devs() function

SFI device_id[] table parsing code is duplicated in every SFI
device handler. This patch removes this code duplication, by
adding a seperate function get_device_id() to parse through the
device table. Also this patch moves the SPI, I2C, IPC info code from
sfi_parse_devs() to respective device handlers.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Link: 
http://lkml.kernel.org/r/1382049336-21316-7-git-send-email-david.a.co...@linux.intel.com
Signed-off-by: David Cohen 
Signed-off-by: H. Peter Anvin 
---
 arch/x86/platform/intel-mid/intel-mid.c | 141 
 1 file changed, 71 insertions(+), 70 deletions(-)

diff --git a/arch/x86/platform/intel-mid/intel-mid.c 
b/arch/x86/platform/intel-mid/intel-mid.c
index 94689ac..d24c729 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -831,20 +831,15 @@ static void __init install_irq_resource(struct 
platform_device *pdev, int irq)
platform_device_add_resources(pdev, , 1);
 }
 
-static void __init sfi_handle_ipc_dev(struct sfi_device_table_entry *entry)
+static void __init sfi_handle_ipc_dev(struct sfi_device_table_entry *pentry,
+   struct devs_id *dev)
 {
-   const struct devs_id *dev = device_ids;
struct platform_device *pdev;
void *pdata = NULL;
 
-   while (dev->name[0]) {
-   if (dev->type == SFI_DEV_TYPE_IPC &&
-   !strncmp(dev->name, entry->name, SFI_NAME_LEN)) {
-   pdata = dev->get_platform_data(entry);
-   break;
-   }
-   dev++;
-   }
+   pr_debug("IPC bus, name = %16.16s, irq = 0x%2x\n",
+   pentry->name, pentry->irq);
+   pdata = dev->get_platform_data(pentry);
 
/*
 * On Medfield the platform device creation is handled by the MSIC
@@ -853,68 +848,94 @@ static void __init sfi_handle_ipc_dev(struct 
sfi_device_table_entry *entry)
if (intel_mid_has_msic())
return;
 
-   pdev = platform_device_alloc(entry->name, 0);
+   pdev = platform_device_alloc(pentry->name, 0);
if (pdev == NULL) {
pr_err("out of memory for SFI platform device '%s'.\n",
-   entry->name);
+   pentry->name);
return;
}
-   install_irq_resource(pdev, entry->irq);
+   install_irq_resource(pdev, pentry->irq);
 
pdev->dev.platform_data = pdata;
intel_scu_device_register(pdev);
 }
 
-static void __init sfi_handle_spi_dev(struct spi_board_info *spi_info)
+static void __init sfi_handle_spi_dev(struct sfi_device_table_entry *pentry,
+   struct devs_id *dev)
 {
-   const struct devs_id *dev = device_ids;
+   struct spi_board_info spi_info;
void *pdata = NULL;
 
-   while (dev->name[0]) {
-   if (dev->type == SFI_DEV_TYPE_SPI &&
-   !strncmp(dev->name, spi_info->modalias,
-   SFI_NAME_LEN)) {
-   pdata = dev->get_platform_data(spi_info);
-   break;
-   }
-   dev++;
-   }
-   spi_info->platform_data = pdata;
+   memset(_info, 0, sizeof(spi_info));
+   strncpy(spi_info.modalias, pentry->name, SFI_NAME_LEN);
+   spi_info.irq = ((pentry->irq == (u8)0xff) ? 0 : pentry->irq);
+   spi_info.bus_num = pentry->host_num;
+   spi_info.chip_select = pentry->addr;
+   spi_info.max_speed_hz = pentry->max_freq;
+   pr_debug("SPI bus=%d, name=%16.16s, irq=0x%2x, max_freq=%d, cs=%d\n",
+   spi_info.bus_num,
+   spi_info.modalias,
+   spi_info.irq,
+   spi_info.max_speed_hz,
+   spi_info.chip_select);
+
+   pdata = dev->get_platform_data(_info);
+
+   spi_info.platform_data = pdata;
if (dev->delay)
-   intel_scu_spi_device_register(spi_info);
+   intel_scu_spi_device_register(_info);
else
-   spi_register_board_info(spi_info, 1);
+   spi_register_board_info(_info, 1);
 }
 
-static void __init sfi_handle_i2c_dev(int bus, struct i2c_board_info *i2c_info)
+static void __init sfi_handle_i2c_dev(struct sfi_device_table_entry *pentry,
+   struct devs_id *dev)
 {
-   const struct devs_id *dev = device_ids;
+   struct i2c_board_info i2c_info;
void *pdata = NULL;
 
+   memset(_info, 0, sizeof(i2c_info));
+   strncpy(i2c_info.type, pentry->name, SFI_NAME_LEN);
+ 

[tip:x86/intel-mid] intel_mid: Renamed *mrst* to *intel_mid*

[tip-bot for Kuppuswamy Sathyanarayanan]

Commit-ID:  05454c26eb3587b56abc5eb139797ac5afb6d77a
Gitweb: http://git.kernel.org/tip/05454c26eb3587b56abc5eb139797ac5afb6d77a
Author: Kuppuswamy Sathyanarayanan 

AuthorDate: Thu, 17 Oct 2013 15:35:27 -0700
Committer:  H. Peter Anvin 
CommitDate: Thu, 17 Oct 2013 16:40:36 -0700

intel_mid: Renamed *mrst* to *intel_mid*

Following files contains code that is common to all intel mid
soc's. So renamed them as below.

mrst/mrst.c  -> intel-mid/intel-mid.c
mrst/vrtc.c  -> intel-mid/intel_mid_vrtc.c
mrst/early_printk_mrst.c -> intel-mid/intel_mid_vrtc.c
pci/mrst.c   -> pci/intel_mid_pci.c

Also, renamed the corresponding header files and made changes
to the driver files that included these header files.

To ensure that there are no functional changes, I have compared
the objdump of renamed files before and after rename and found
that the only difference is file name change.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Link: 
http://lkml.kernel.org/r/1382049336-21316-4-git-send-email-david.a.co...@linux.intel.com
Signed-off-by: David Cohen 
Signed-off-by: H. Peter Anvin 
---
 arch/x86/include/asm/{mrst.h => intel-mid.h}  |  8 
 arch/x86/include/asm/{mrst-vrtc.h => intel_mid_vrtc.h}|  4 ++--
 arch/x86/kernel/apb_timer.c   |  2 +-
 arch/x86/kernel/early_printk.c|  2 +-
 arch/x86/kernel/rtc.c |  2 +-
 arch/x86/pci/Makefile |  2 +-
 arch/x86/pci/{mrst.c => intel_mid_pci.c}  |  2 +-
 arch/x86/platform/Makefile|  2 +-
 arch/x86/platform/intel-mid/Makefile  |  3 +++
 .../early_printk_intel_mid.c} |  4 ++--
 arch/x86/platform/{mrst/mrst.c => intel-mid/intel-mid.c}  | 11 ++-
 arch/x86/platform/{mrst/vrtc.c => intel-mid/intel_mid_vrtc.c} |  6 +++---
 arch/x86/platform/mrst/Makefile   |  3 ---
 drivers/gpu/drm/gma500/mdfld_dsi_output.h |  2 +-
 drivers/gpu/drm/gma500/oaktrail_device.c  |  2 +-
 drivers/gpu/drm/gma500/oaktrail_lvds.c|  2 +-
 drivers/platform/x86/intel_scu_ipc.c  |  2 +-
 drivers/rtc/rtc-mrst.c|  4 ++--
 drivers/watchdog/intel_scu_watchdog.c |  2 +-
 19 files changed, 33 insertions(+), 32 deletions(-)

diff --git a/arch/x86/include/asm/mrst.h b/arch/x86/include/asm/intel-mid.h
similarity index 93%
rename from arch/x86/include/asm/mrst.h
rename to arch/x86/include/asm/intel-mid.h
index fc18bf3..cc79a4f 100644
--- a/arch/x86/include/asm/mrst.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -1,5 +1,5 @@
 /*
- * mrst.h: Intel Moorestown platform specific setup code
+ * intel-mid.h: Intel MID specific setup code
  *
  * (C) Copyright 2009 Intel Corporation
  *
@@ -8,8 +8,8 @@
  * as published by the Free Software Foundation; version 2
  * of the License.
  */
-#ifndef _ASM_X86_MRST_H
-#define _ASM_X86_MRST_H
+#ifndef _ASM_X86_INTEL_MID_H
+#define _ASM_X86_INTEL_MID_H
 
 #include 
 
@@ -78,4 +78,4 @@ extern void intel_scu_devices_destroy(void);
 
 extern void mrst_rtc_init(void);
 
-#endif /* _ASM_X86_MRST_H */
+#endif /* _ASM_X86_INTEL_MID_H */
diff --git a/arch/x86/include/asm/mrst-vrtc.h 
b/arch/x86/include/asm/intel_mid_vrtc.h
similarity index 81%
rename from arch/x86/include/asm/mrst-vrtc.h
rename to arch/x86/include/asm/intel_mid_vrtc.h
index 1e69a75..86ff468 100644
--- a/arch/x86/include/asm/mrst-vrtc.h
+++ b/arch/x86/include/asm/intel_mid_vrtc.h
@@ -1,5 +1,5 @@
-#ifndef _MRST_VRTC_H
-#define _MRST_VRTC_H
+#ifndef _INTEL_MID_VRTC_H
+#define _INTEL_MID_VRTC_H
 
 extern unsigned char vrtc_cmos_read(unsigned char reg);
 extern void vrtc_cmos_write(unsigned char val, unsigned char reg);
diff --git a/arch/x86/kernel/apb_timer.c b/arch/x86/kernel/apb_timer.c
index c9876ef..9154836 100644
--- a/arch/x86/kernel/apb_timer.c
+++ b/arch/x86/kernel/apb_timer.c
@@ -40,7 +40,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #define APBT_CLOCKEVENT_RATING 110
diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
index d15f575..38ca398 100644
--- a/arch/x86/kernel/early_printk.c
+++ b/arch/x86/kernel/early_printk.c
@@ -14,7 +14,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c
index 0aa2939..a1b52fe 100644
--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #ifdef CONFIG_X86_32
diff --git a/arch/x86/pci/Makefile b/arch/x86/pci/Makefile
index ee0af58..e063eed 100644
--- a/arch/x86/pci/Makefile
+++ b/arch/x86/pci/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_X86_VISWS)   += visws.o
 

[tip:x86/intel-mid] mrst: Fixed indentation issues

[tip-bot for Kuppuswamy Sathyanarayanan]

Commit-ID:  d8059302b374b351731ba503bb6f5bc88962d983
Gitweb: http://git.kernel.org/tip/d8059302b374b351731ba503bb6f5bc88962d983
Author: Kuppuswamy Sathyanarayanan 

AuthorDate: Thu, 17 Oct 2013 15:35:26 -0700
Committer:  H. Peter Anvin 
CommitDate: Thu, 17 Oct 2013 16:40:35 -0700

mrst: Fixed indentation issues

Fixed indentation issues reported by checkpatch script in
mrst related files.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Link: 
http://lkml.kernel.org/r/1382049336-21316-3-git-send-email-david.a.co...@linux.intel.com
Signed-off-by: David Cohen 
Signed-off-by: H. Peter Anvin 
---
 arch/x86/platform/mrst/early_printk_mrst.c |  3 ++-
 arch/x86/platform/mrst/mrst.c  | 24 +---
 2 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/arch/x86/platform/mrst/early_printk_mrst.c 
b/arch/x86/platform/mrst/early_printk_mrst.c
index 95880f7..39ecc27 100644
--- a/arch/x86/platform/mrst/early_printk_mrst.c
+++ b/arch/x86/platform/mrst/early_printk_mrst.c
@@ -219,7 +219,8 @@ static void early_mrst_spi_putc(char c)
 }
 
 /* Early SPI only uses polling mode */
-static void early_mrst_spi_write(struct console *con, const char *str, 
unsigned n)
+static void early_mrst_spi_write(struct console *con, const char *str,
+   unsigned n)
 {
int i;
 
diff --git a/arch/x86/platform/mrst/mrst.c b/arch/x86/platform/mrst/mrst.c
index b9aeb54..235a742 100644
--- a/arch/x86/platform/mrst/mrst.c
+++ b/arch/x86/platform/mrst/mrst.c
@@ -131,7 +131,7 @@ struct sfi_timer_table_entry *sfi_get_mtmr(int hint)
int i;
if (hint < sfi_mtimer_num) {
if (!sfi_mtimer_usage[hint]) {
-   pr_debug("hint taken for timer %d irq %d\n",\
+   pr_debug("hint taken for timer %d irq %d\n",
hint, sfi_mtimer_array[hint].irq);
sfi_mtimer_usage[hint] = 1;
return _mtimer_array[hint];
@@ -679,14 +679,14 @@ static void *msic_thermal_platform_data(void *info)
 /* tc35876x DSI-LVDS bridge chip and panel platform data */
 static void *tc35876x_platform_data(void *data)
 {
-   static struct tc35876x_platform_data pdata;
+   static struct tc35876x_platform_data pdata;
 
-   /* gpio pins set to -1 will not be used by the driver */
-   pdata.gpio_bridge_reset = get_gpio_by_name("LCMB_RXEN");
-   pdata.gpio_panel_bl_en = get_gpio_by_name("6S6P_BL_EN");
-   pdata.gpio_panel_vadd = get_gpio_by_name("EN_VREG_LCD_V3P3");
+   /* gpio pins set to -1 will not be used by the driver */
+   pdata.gpio_bridge_reset = get_gpio_by_name("LCMB_RXEN");
+   pdata.gpio_panel_bl_en = get_gpio_by_name("6S6P_BL_EN");
+   pdata.gpio_panel_vadd = get_gpio_by_name("EN_VREG_LCD_V3P3");
 
-   return 
+   return 
 }
 
 static const struct devs_id __initconst device_ids[] = {
@@ -729,7 +729,7 @@ static int i2c_next_dev;
 
 static void __init intel_scu_device_register(struct platform_device *pdev)
 {
-   if(ipc_next_dev == MAX_IPCDEVS)
+   if (ipc_next_dev == MAX_IPCDEVS)
pr_err("too many SCU IPC devices");
else
ipc_devs[ipc_next_dev++] = pdev;
@@ -872,7 +872,8 @@ static void __init sfi_handle_spi_dev(struct spi_board_info 
*spi_info)
 
while (dev->name[0]) {
if (dev->type == SFI_DEV_TYPE_SPI &&
-   !strncmp(dev->name, spi_info->modalias, 
SFI_NAME_LEN)) {
+   !strncmp(dev->name, spi_info->modalias,
+   SFI_NAME_LEN)) {
pdata = dev->get_platform_data(spi_info);
break;
}
@@ -904,7 +905,7 @@ static void __init sfi_handle_i2c_dev(int bus, struct 
i2c_board_info *i2c_info)
intel_scu_i2c_device_register(bus, i2c_info);
else
i2c_register_board_info(bus, i2c_info, 1);
- }
+}
 
 
 static int __init sfi_parse_devs(struct sfi_table_header *table)
@@ -1034,7 +1035,8 @@ static int __init pb_keys_init(void)
num = sizeof(gpio_button) / sizeof(struct gpio_keys_button);
for (i = 0; i < num; i++) {
gb[i].gpio = get_gpio_by_name(gb[i].desc);
-   pr_debug("info[%2d]: name = %s, gpio = %d\n", i, gb[i].desc, 
gb[i].gpio);
+   pr_debug("info[%2d]: name = %s, gpio = %d\n", i, gb[i].desc,
+   gb[i].gpio);
if (gb[i].gpio == -1)
continue;
 
--
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: mm, numa: test segfaults, only when NUMA balancing is on

[Alex Thorlton]

On Thu, Oct 17, 2013 at 07:30:58PM +0800, Bob Liu wrote:
> Hi Alex,
> 
> On Wed, Oct 16, 2013 at 11:54 PM, Alex Thorlton  wrote:
> > Hi guys,
> >
> > I ran into a bug a week or so ago, that I believe has something to do
> > with NUMA balancing, but I'm having a tough time tracking down exactly
> > what is causing it.  When running with the following configuration
> > options set:
> >
> > CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
> > CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
> > CONFIG_NUMA_BALANCING=y
> > # CONFIG_HUGETLBFS is not set
> > # CONFIG_HUGETLB_PAGE is not set
> >
> 
> What's your kernel version?
> And did you enable CONFIG_TRANSPARENT_HUGEPAGE ?

Ah, two important things that I forgot to include!  The kernel I
originally spotted the problem on was 3.11 and it continued to be an
issue up through 3.12-rc4, but after running a 30-trial run of the
test today, it appears that the issue must have cleared up after the
3.12-rc5 release on Monday.  I'll still include the requested
information, but I guess this is no longer an issue.

I rolled all the way back to 3.7 while researching the issue, and that
appears to be the last kernel where the problem didn't show up.  3.8
is the first kernel where the bug appears; I believe this is also the
kernel where NUMA balancing was officially introduced.

Here are my settings related to THP:

CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set

I did most of my testing with THP set to "always", although the problem
still occurs with THP set to "never".  

> 
> > I get intermittent segfaults when running the memscale test that we've
> > been using to test some of the THP changes.  Here's a link to the test:
> >
> > ftp://shell.sgi.com/collect/memscale/
> >
> > I typically run the test with a line similar to this:
> >
> > ./thp_memscale -C 0 -m 0 -c  -b 
> >
> > Where  is the number of cores to spawn threads on, and 
> > is the amount of memory to reserve from each core.  The  field
> > can accept values like 512m or 1g, etc.  I typically run 256 cores and
> > 512m, though I think the problem should be reproducable on anything with
> > 128+ cores.
> >
> > The test never seems to have any problems when running with hugetlbfs
> > on and NUMA balancing off, but it segfaults every once in a while with
> > the config options above.  It seems to occur more frequently, the more
> > cores you run on.  It segfaults on about 50% of the runs at 256 cores,
> > and on almost every run at 512 cores.  The fewest number of cores I've
> > seen a segfault on has been 128, though it seems to be rare on this many
> > cores.
> >
> 
> Could you please attach some logs?

Here are the relevant chunks from the syslog for a 10-shot run at 256
cores, each chunk is from a separate run.  4 out of 10 failed with
segfaults:

Oct 17 11:36:41 harp83-sys kernel: thp_memscale[21566]: segfault at 0 ip
   (null) sp 7ff8531fcdc0 error 14 in thp_memscale[40+5000]
Oct 17 11:36:41 harp83-sys kernel: thp_memscale[21565]: segfault at 0 ip
   (null) sp 7ff8539fddc0 error 14 in thp_memscale[40+5000]
---
Oct 17 12:08:14 harp83-sys kernel: thp_memscale[22893]: segfault at 0 ip
   (null) sp 7ff69cffddc0 error 14 in thp_memscale[40+5000]
---
Oct 17 12:26:30 harp83-sys kernel: thp_memscale[23995]: segfault at 0 ip
   (null) sp 7fe7af1fcdc0 error 14 in thp_memscale[40+5000]
Oct 17 12:26:30 harp83-sys kernel: thp_memscale[23994]: segfault at 0 ip
   (null) sp 7fe7af9fddc0 error 14 in thp_memscale[40+5000]
---
Oct 17 12:32:29 harp83-sys kernel: thp_memscale[24116]: segfault at 0 ip
   (null) sp 7ff77a9fcdc0 error 14 in thp_memscale[40+5000]

Since this has cleared up in the latest release, I won't be pursuing the
issue any further (though I'll keep an eye out to make sure that it
doesn't show back up).  I am, however, still curious as to what the
cause of the problem was...

> 
> > At this point, I'm not familiar enough with NUMA balancing code to know
> > what could be causing this, and we don't typically run with NUMA
> > balancing on, so I don't see this in my everyday testing, but I felt
> > that it was definitely worth bringing up.
> >
> > If anybody has any ideas of where I could poke around to find a
> > solution, please let me know.
> >
> 
> -- 
> Regards,
> --Bob
--
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/

[REVIEW][PATCH] userns: Remove UIDGID_STRICT_TYPE_CHECKS

[Eric W. Biederman]

Removing UIDGID_STRICT_TYPE_CHECKS simplifies the code and always
generates a compile error if the uids and kuids or gids and kgids are
mixed by accident.  Now that the appropriate conversions have been
placed throughout the kernel there is no longer a need for a mode where
we don't detect them as compile errors.

Acked-by: Serge Hallyn 
Signed-off-by: Eric W. Biederman 
---
 include/linux/posix_acl.h |3 ---
 include/linux/projid.h|   15 ---
 include/linux/uidgid.h|   22 --
 init/Kconfig  |   11 ---
 4 files changed, 0 insertions(+), 51 deletions(-)

diff --git a/include/linux/posix_acl.h b/include/linux/posix_acl.h
index 7931efe71175..f0f7746b2359 100644
--- a/include/linux/posix_acl.h
+++ b/include/linux/posix_acl.h
@@ -39,9 +39,6 @@ struct posix_acl_entry {
union {
kuid_t  e_uid;
kgid_t  e_gid;
-#ifndef CONFIG_UIDGID_STRICT_TYPE_CHECKS
-   unsigned inte_id;
-#endif
};
 };
 
diff --git a/include/linux/projid.h b/include/linux/projid.h
index 36517b95be5c..8c1f2c55226d 100644
--- a/include/linux/projid.h
+++ b/include/linux/projid.h
@@ -18,8 +18,6 @@ extern struct user_namespace init_user_ns;
 
 typedef __kernel_uid32_t projid_t;
 
-#ifdef CONFIG_UIDGID_STRICT_TYPE_CHECKS
-
 typedef struct {
projid_t val;
 } kprojid_t;
@@ -31,19 +29,6 @@ static inline projid_t __kprojid_val(kprojid_t projid)
 
 #define KPROJIDT_INIT(value) (kprojid_t){ value }
 
-#else
-
-typedef projid_t kprojid_t;
-
-static inline projid_t __kprojid_val(kprojid_t projid)
-{
-   return projid;
-}
-
-#define KPROJIDT_INIT(value) ((kprojid_t) value )
-
-#endif
-
 #define INVALID_PROJID KPROJIDT_INIT(-1)
 #define OVERFLOW_PROJID 65534
 
diff --git a/include/linux/uidgid.h b/include/linux/uidgid.h
index 8e522cbcef29..2d1f9b627f91 100644
--- a/include/linux/uidgid.h
+++ b/include/linux/uidgid.h
@@ -17,8 +17,6 @@
 struct user_namespace;
 extern struct user_namespace init_user_ns;
 
-#ifdef CONFIG_UIDGID_STRICT_TYPE_CHECKS
-
 typedef struct {
uid_t val;
 } kuid_t;
@@ -41,26 +39,6 @@ static inline gid_t __kgid_val(kgid_t gid)
return gid.val;
 }
 
-#else
-
-typedef uid_t kuid_t;
-typedef gid_t kgid_t;
-
-static inline uid_t __kuid_val(kuid_t uid)
-{
-   return uid;
-}
-
-static inline gid_t __kgid_val(kgid_t gid)
-{
-   return gid;
-}
-
-#define KUIDT_INIT(value) ((kuid_t) value )
-#define KGIDT_INIT(value) ((kgid_t) value )
-
-#endif
-
 #define GLOBAL_ROOT_UID KUIDT_INIT(0)
 #define GLOBAL_ROOT_GID KGIDT_INIT(0)
 
diff --git a/init/Kconfig b/init/Kconfig
index 3ecd8a1178f1..b40280b640cc 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1123,8 +1123,6 @@ config IPC_NS
 
 config USER_NS
bool "User namespace"
-   select UIDGID_STRICT_TYPE_CHECKS
-
default n
help
  This allows containers, i.e. vservers, to use user namespaces
@@ -1156,15 +1154,6 @@ config NET_NS
 
 endif # NAMESPACES
 
-config UIDGID_STRICT_TYPE_CHECKS
-   bool "Require conversions between uid/gids and their internal 
representation"
-   default n
-   help
-While the nececessary conversions are being added to all subsystems 
this option allows
-the code to continue to build for unconverted subsystems.
-
-Say Y here if you want the strict type checking enabled
-
 config SCHED_AUTOGROUP
bool "Automatic process group scheduling"
select EVENTFD
-- 
1.7.5.4

--
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/kernel-doc: make unknown function prototype a Warning instead of an Error

[Mark Brown]

On Thu, Oct 17, 2013 at 04:32:01PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap 
> 
> When scripts/kernel-doc cannot understand a function prototype,
> it had been generating a fatal error and stopping immediately.
> Make this a Warning instead of an Error and keep going.

Thanks!


signature.asc
Description: Digital signature

Re: [PATCH 09/29] hexagon: Use get_signal() signal_setup_done()

[rkuo]

On Tue, Oct 08, 2013 at 01:32:22PM +0200, Richard Weinberger wrote:
> Use the more generic functions get_signal() signal_setup_done()
> for signal delivery.
> 
> Signed-off-by: Richard Weinberger 

Thanks for the changes.  Compiled and tested briefly; the Hexagon part of
this looks fine.

If you want to compile test, there are newer versions of the toolchain
available here:

https://sourcery.mentor.com/GNUToolchain/release2568



Acked-by: Richard Kuo 

-- 

Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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 2/2] KVM: x86: fix KVM_SET_XCRS loop

[Marcelo Tosatti]

On Thu, Oct 17, 2013 at 04:50:47PM +0200, Paolo Bonzini wrote:
> The loop was always using 0 as the index.  This means that
> any rubbish after the first element of the array went undetected.
> It seems reasonable to assume that no KVM userspace did that.

It is not a typo, look at __kvm_set_xcr when setting
guest_xcrs->xcrs[i].value, with i != 0.

The code is not prepared to deal with XCR != 0 (because its not
implemented in hw).

> Signed-off-by: Paolo Bonzini 
> ---
>  arch/x86/kvm/x86.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index f4e1391..f91dff2 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -3062,9 +3062,9 @@ static int kvm_vcpu_ioctl_x86_set_xcrs(struct kvm_vcpu 
> *vcpu,
>  
>   for (i = 0; i < guest_xcrs->nr_xcrs; i++)
>   /* Only support XCR0 currently */
> - if (guest_xcrs->xcrs[0].xcr == XCR_XFEATURE_ENABLED_MASK) {
> + if (guest_xcrs->xcrs[i].xcr == XCR_XFEATURE_ENABLED_MASK) {
>   r = __kvm_set_xcr(vcpu, XCR_XFEATURE_ENABLED_MASK,
> - guest_xcrs->xcrs[0].value);
> + guest_xcrs->xcrs[i].value);
>   break;
>   }
>   if (r)
> -- 
> 1.8.3.1
--
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] regmap: irq: clear status when disable irq

[Mark Brown]

On Tue, Oct 15, 2013 at 08:23:30PM +0800, Yi Zhang wrote:

I'm still not sure this is doing the right thing.

> + for (j = 0; j < bits_length; j++) {
> + if (!(d->mask_buf[i] & (0x1 << j))) {

This is checking to see if the bit is masked...

> + ret = regmap_update_bits(d->map, reg,
> +  (0x1 << j), 0);

...then writing a zero to that bit.  For most chips with a write 1 to
clear acknowledge this will result in all set bits in the register being
acked except the currently masked one (though if there are two masked
bits all will be acked).

It would be much quicker to just write mask_buf[i] back to the device to
acknoweldge all masked bits at once rather than try to do it
individually and the result should be the same unless the chip requires
us to set zero (which probably ought to be a quirk).


signature.asc
Description: Digital signature

Re: [PATCH net-next v3 3/9] static_key: WARN on usage before jump_label_init was called

[Hannes Frederic Sowa]

On Thu, Oct 17, 2013 at 05:19:40PM -0400, Steven Rostedt wrote:
> On Thu, 17 Oct 2013 07:31:57 +0200
> Hannes Frederic Sowa  wrote:
> 
> > Based on a patch from Andi Kleen.
> 
> I'm fine with the patch, but the change log needs a lot more work.
> Like, why is this needed?  I know, but does anyone else?

Ok. :)

I'll move the description from the changelog here and write something
in a few days (hope to get more feedback on the other parts, especially
net_get_random_once).

Does that also mean you are in principle ok with the patch weakening
the check in arch/x86/jump_label.c?

Thanks for the review,

  Hannes

--
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/3 v2] regulator: core: Add ability to create a lookup alias for supply

[Mark Brown]

On Tue, Oct 15, 2013 at 08:14:20PM +0100, Charles Keepax wrote:
> These patches add the ability to create an alternative device on which
> a lookup for a certain supply should be conducted.

Applied, thanks.  This can't really be applied without pulling in large
chunks of the regulator changes due to some refactoring in the core that
it depends on, I've created a tag supply-alias but it's got a nasty diff
so it's probably best if I apply the other two patches to the regulator
tree?


signature.asc
Description: Digital signature

Re: [PATCH] of/lib: Export fdt routines to modules

[Michael Bohan]

On Wed, Oct 16, 2013 at 09:54:27PM -0700, Guenter Roeck wrote:
> On 10/16/2013 05:27 PM, Michael Bohan wrote:
> >My motivation is actually to use the fdt format as a firmware.
> >I have a requirement to express driver metadata that's loadable
> >from the filesystem. This data is not reasonable to place in the
> >system Device Tree, since it's application specific and does not
> >actually describe hardware. The fact that the format chosen is
> >'flattened device tree' is merely just a coincidence.
> >
> Still, what prevents you from unflattening it and just using the
> normal device tree functions as David suggested ?

I'm assuming you're suggesting to use of_fdt_unflatten_tree()?
That's an interesting thought. I was planning to scan the fdt
only once and populate my own structures, but I suppose I could
use the of_* APIs equivalently.

It seems there are some problems though.  of_fdt_unflatten_tree()
does not return errors, and so for the purposes of my driver it
would not be sufficient to detect an invalid firmware image. 

Would people entertain changing this API
(and implicitly __unflatten_device_tree) to return errors? I'm
guessing the reason it's coded that way is because the normal
usecase is 'system boot', at which time errors aren't that
meaningful.

Also, there's no way to free the memory that was allocated from
the unflatten process. May I add one?

Thanks,
Mike

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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 10/15] clk: tegra: move audio clk to common file

[Andrew Bresticker]

Hi Peter,

> +static struct tegra_clk tegra114_clks[tegra_clk_max] __initdata = {

Not really a big deal, but a lot of these clocks are not audio
related.  Maybe they should be added when the common infrastructure to
deal with them is added?

Thanks,
Andrew
--
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] ARM: s3c64xx: Select CPU_V6K instead of CPU_V6

[Kukjin Kim]

Tomasz Figa wrote:
> 
> Hi Kukjin,
> 
> On Saturday 28 of September 2013 19:49:14 Tomasz Figa wrote:
> > All S3C64XX SoCs come with ARM1176JZF-s core, which fully supports
> > ARMv6K extensions. This patch lets the kernel use them on S3C6410 by
> > adding selection of CPU_V6K to ARCH_S3C64XX.
> >
> > Signed-off-by: Tomasz Figa 
> > ---
> >  arch/arm/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> What do you think about this patch?
> 
Yeah, ARM1176JZF-s is correct. Applied.

Thanks,
Kukjin

> Best regards,
> Tomasz
> 
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index b766dad..3a41bbb 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -728,7 +728,7 @@ config ARCH_S3C64XX
> > select CLKDEV_LOOKUP
> > select CLKSRC_SAMSUNG_PWM
> > select COMMON_CLK
> > -   select CPU_V6
> > +   select CPU_V6K
> > select GENERIC_CLOCKEVENTS
> > select GPIO_SAMSUNG
> > select HAVE_CLK

--
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] ARM: s3c64xx: mini6410: Correct card detect type for HSMMC1

[Kukjin Kim]

Tomasz Figa wrote:
> 
> Hi Kukjin,
> 
Hi,

> On Sunday 29 of September 2013 18:12:01 Tomasz Figa wrote:
> > According to board schematics, for HSMMC1 a GPIO line is used to detect
> > card presence, while currently it is being configured for internal card
> > detect line, which is multiplexed with card detect line of HSMMC0 and
> > thus breaking it.
> >
> > This patch adds proper sdhci platform data setting card detect type to
> > external GPIO and fixing operation of HSMMC0.
> >
> > Signed-off-by: Tomasz Figa 
> > ---
> >  arch/arm/mach-s3c64xx/mach-mini6410.c | 10 ++
> >  1 file changed, 10 insertions(+)
> 
> Would you mind taking this patch to your tree?
> 
Applied, thanks.
Kukjin

> Best regards,
> Tomasz
> 
> > diff --git a/arch/arm/mach-s3c64xx/mach-mini6410.c
> > b/arch/arm/mach-s3c64xx/mach-mini6410.c index 58d46a3..97ae470 100644
> > --- a/arch/arm/mach-s3c64xx/mach-mini6410.c
> > +++ b/arch/arm/mach-s3c64xx/mach-mini6410.c
> > @@ -36,7 +36,9 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> > +#include 
> >  #include 
> >
> >  #include 
> > @@ -214,6 +216,13 @@ static struct platform_device mini6410_lcd_powerdev
> > = { .dev.platform_data  = _lcd_power_data,
> >  };
> >
> > +static struct s3c_sdhci_platdata mini6410_hsmmc1_pdata = {
> > +   .max_width  = 4,
> > +   .cd_type= S3C_SDHCI_CD_GPIO,
> > +   .ext_cd_gpio= S3C64XX_GPN(10),
> > +   .ext_cd_gpio_invert = true,
> > +};
> > +
> >  static struct platform_device *mini6410_devices[] __initdata = {
> > _device_eth,
> > _device_hsmmc0,
> > @@ -321,6 +330,7 @@ static void __init mini6410_machine_init(void)
> >
> > s3c_nand_set_platdata(_nand_info);
> > s3c_fb_set_platdata(_lcd_pdata[features.lcd_index]);
> > +   s3c_sdhci1_set_platdata(_hsmmc1_pdata);
> > s3c24xx_ts_set_platdata(NULL);
> >
> > /* configure nCS1 width to 16 bits */

--
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: spi-s3c64xx: Add missing pm_runtime_put on setup fail

[Mark Brown]

On Thu, Oct 17, 2013 at 02:45:41PM +0200, Krzysztof Kozlowski wrote:
> pm_runtime_put() wasn't called if clock rate could not be set up in
> s3c64xx_spi_setup() leading to invalid count of device pm_runtime usage.

Applied, thanks.


signature.asc
Description: Digital signature

Re: [PATCH] spi/s3c64xx: Add missing pm_runtime_set_active() call in probe()

[Mark Brown]

On Thu, Oct 17, 2013 at 06:06:46PM +0200, Krzysztof Kozlowski wrote:
> Mark device as PM runtime active during initialization to reflect
> actual device power/clocks state. This reduces the enable count for SPI
> bus controller gate clock so it can be disabled when the bus controller
> is not used.

Applied, thanks.


signature.asc
Description: Digital signature

[PATCH] scripts/kernel-doc: make unknown function prototype a Warning instead of an Error

[Randy Dunlap]

From: Randy Dunlap 

When scripts/kernel-doc cannot understand a function prototype,
it had been generating a fatal error and stopping immediately.
Make this a Warning instead of an Error and keep going.

Note that this can happen if the kernel-doc notation that is being
parsed is not actually a function prototype; maybe it's a struct or
something else, so I added "function" to the warning message to try
to make it clearer that scripts/kernel-doc is looking for a function
prototype here.

Signed-off-by: Randy Dunlap 
Cc: Mark Brown 
---
 scripts/kernel-doc |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- linux-3.12-rc5.orig/scripts/kernel-doc
+++ linux-3.12-rc5/scripts/kernel-doc
@@ -2125,8 +2125,7 @@ sub dump_function($$) {
 
create_parameterlist($args, ',', $file);
 } else {
-   print STDERR "Error(${file}:$.): cannot understand prototype: 
'$prototype'\n";
-   ++$errors;
+   print STDERR "Warning(${file}:$.): cannot understand function 
prototype: '$prototype'\n";
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/

Re: [PATCH 5/5] efi: Capsule update support and pstore backend

[Andi Kleen]

> > I'm a little uneasy having this run by default if enabled, even if it's 
> > disabled by default in the config.
> 
> What would be the canonical way to enable this feature then? Have a file

White list systems and a option to force enable.

-Andi

--
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 5/5] efi: Capsule update support and pstore backend

[Andi Kleen]

> But, as Eric said, it should be OK if it is implemented in the kdump kenel.

kdump doesn't work for a lot of use cases (too much memory consumption)

-Andi
--
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: trace-cmd problem with FC19

[Steven Rostedt]

On Thu, 17 Oct 2013 17:11:43 -0400
Bob Copeland  wrote:

> On Thu, Oct 17, 2013 at 04:56:56PM -0400, Steven Rostedt wrote:
> > Hmm, are you sure?
> > 
> > You may want to do both:
> > 
> > sudo trace-cmd -v
> > which trace-cmd
> > 
> > to see which version it is.
> 
> To clarify - I ran into the referenced issue using an older,
> self-compiled version with a recent kernel.  The FC19 distro
> version may be fine, for all I know.
> 
> Arend says he used the latest version from the repo which should
> not be a problem, but just throwing that out there since the
> symptoms are similar.
> 

Yeah, there was a known breakage in 3.10. The problem was that the
breakage was a fix to the splice code that would help trace-cmd.
Unfortunately, trace-cmd had a bug in it that would cause the fix to
break it.

I released a fix for all versions of trace-cmd that's currently
supported, and some that are not (all the way down to the 1.0 series).
I had the fix go out several months before 3.10 was released, and
notified all the major distros about it.

Thus, if you are using an older version, then yes, it will be broken
with the newer kernel. Just upgrade to a newer release (you can even
keep the same X.X version as they all have the fix).

-- Steve
--
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: [Kernel-BR] Re: [PATCH] sound: pci: emu10k1: code refactoring and casting removal

[Geyslan Gregório Bem]

2013/10/17 Raphael S Carvalho :
>> 2013/10/17 Takashi Iwai :
>>>
>>> Geyslan, you don't have to waste too much of your time (and my time
>>> for review) for this kind of so old driver code unless it really fixes
>>> the bugs.  A clean up is good in general, but it can be sometimes
>>> worse than nothing since it also breaks the history, thus makes hard
>>> to follow via "git blame", for example, and of course, there is always
>>> a potential danger of regression.
>>>
>>> So, if it's about clean up, do it only in a systematic way that others
>>> can follow easily, and don't do it too intensively.
>>>
>>>
>>> thanks,
>>>
>>> Takashi
Takashi,

I sent the last version:
[PATCH v3] sound: pci: emu10k1: code refactoring

Regards.

>
> His code refactoring proposal is welcome since the old code sucks from
> several points of view, e.g. maintainability, legibility, etc.
> Yes, of course, it's important to be careful in order not to introduce
> regressions. And yes, he could improve something here and there.
> As long as changes improve the maintainability and legibility of the
> code, there is no reason to refuse them.
>
> --
> Raphael S. Carvalho

Raphael, thank you for reply.

Regards.
--
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 v3] sound: pci: emu10k1: code refactoring

[Geyslan G. Bem]

Partially restructures _snd_emu10k1_audigy_init_efx() and
_snd_emu10k1_init_efx() functions.

Be noted that the cast is demanded to use '__user'. So, in these cases,
avoid patches based on the coccinelle 'drop_kmalloc_cast' semantic patch.

Signed-off-by: Geyslan G. Bem 
---
 sound/pci/emu10k1/emufx.c | 76 ---
 1 file changed, 45 insertions(+), 31 deletions(-)

diff --git a/sound/pci/emu10k1/emufx.c b/sound/pci/emu10k1/emufx.c
index 0275209..1f9c7c4 100644
--- a/sound/pci/emu10k1/emufx.c
+++ b/sound/pci/emu10k1/emufx.c
@@ -1182,15 +1182,20 @@ static int _snd_emu10k1_audigy_init_efx(struct 
snd_emu10k1 *emu)
u32 *gpr_map;
mm_segment_t seg;
 
-   if ((icode = kzalloc(sizeof(*icode), GFP_KERNEL)) == NULL ||
-   (icode->gpr_map = (u_int32_t __user *)
-kcalloc(512 + 256 + 256 + 2 * 1024, sizeof(u_int32_t),
-GFP_KERNEL)) == NULL ||
-   (controls = kcalloc(SND_EMU10K1_GPR_CONTROLS,
-   sizeof(*controls), GFP_KERNEL)) == NULL) {
-   err = -ENOMEM;
-   goto __err;
-   }
+   err = -ENOMEM;
+   icode = kzalloc(sizeof(*icode), GFP_KERNEL);
+   if (!icode)
+   return err;
+
+   icode->gpr_map = (u_int32_t __user *) kcalloc(512 + 256 + 256 + 2 * 
1024,
+ sizeof(u_int32_t), 
GFP_KERNEL);
+   if (!icode->gpr_map)
+   goto __err_gpr;
+   controls = kcalloc(SND_EMU10K1_GPR_CONTROLS,
+  sizeof(*controls), GFP_KERNEL);
+   if (!controls)
+   goto __err_ctrls;
+
gpr_map = (u32 __force *)icode->gpr_map;
 
icode->tram_data_map = icode->gpr_map + 512;
@@ -1741,12 +1746,12 @@ A_OP(icode, , iMAC0, A_GPR(var), A_GPR(var), 
A_GPR(vol), A_EXTIN(input))
emu->support_tlv = 0; /* clear again */
snd_leave_user(seg);
 
- __err:
+__err:
kfree(controls);
-   if (icode != NULL) {
-   kfree((void __force *)icode->gpr_map);
-   kfree(icode);
-   }
+__err_ctrls:
+   kfree((void __force *)icode->gpr_map);
+__err_gpr:
+   kfree(icode);
return err;
 }
 
@@ -1813,18 +1818,26 @@ static int _snd_emu10k1_init_efx(struct snd_emu10k1 
*emu)
u32 *gpr_map;
mm_segment_t seg;
 
-   if ((icode = kzalloc(sizeof(*icode), GFP_KERNEL)) == NULL)
-   return -ENOMEM;
-   if ((icode->gpr_map = (u_int32_t __user *)
-kcalloc(256 + 160 + 160 + 2 * 512, sizeof(u_int32_t),
-GFP_KERNEL)) == NULL ||
-(controls = kcalloc(SND_EMU10K1_GPR_CONTROLS,
-   sizeof(struct snd_emu10k1_fx8010_control_gpr),
-   GFP_KERNEL)) == NULL ||
-   (ipcm = kzalloc(sizeof(*ipcm), GFP_KERNEL)) == NULL) {
-   err = -ENOMEM;
-   goto __err;
-   }
+   err = -ENOMEM;
+   icode = kzalloc(sizeof(*icode), GFP_KERNEL);
+   if (!icode)
+   return err;
+
+   icode->gpr_map = (u_int32_t __user *) kcalloc(256 + 160 + 160 + 2 * 512,
+ sizeof(u_int32_t), 
GFP_KERNEL);
+   if (!icode->gpr_map)
+   goto __err_gpr;
+
+   controls = kcalloc(SND_EMU10K1_GPR_CONTROLS,
+  sizeof(struct snd_emu10k1_fx8010_control_gpr),
+  GFP_KERNEL);
+   if (!controls)
+   goto __err_ctrls;
+
+   ipcm = kzalloc(sizeof(*ipcm), GFP_KERNEL);
+   if (!ipcm)
+   goto __err_ipcm;
+
gpr_map = (u32 __force *)icode->gpr_map;
 
icode->tram_data_map = icode->gpr_map + 256;
@@ -2363,13 +2376,14 @@ static int _snd_emu10k1_init_efx(struct snd_emu10k1 
*emu)
snd_leave_user(seg);
if (err >= 0)
err = snd_emu10k1_ipcm_poke(emu, ipcm);
-  __err:
+__err:
kfree(ipcm);
+__err_ipcm:
kfree(controls);
-   if (icode != NULL) {
-   kfree((void __force *)icode->gpr_map);
-   kfree(icode);
-   }
+__err_ctrls:
+   kfree((void __force *)icode->gpr_map);
+__err_gpr:
+   kfree(icode);
return err;
 }
 
-- 
1.8.4

--
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] leds: Added driver for the NXP PCA9685 I2C chip

[Maximilian Güntner]

Hello Bryan,

thank you for applying the patch so quickly.

Maximilian

2013/10/18 Bryan Wu :
> On Wed, Oct 16, 2013 at 6:09 PM, Maximilian Güntner
>  wrote:
>> The NXP PCA9685 supports 16 channels/leds using a 12-bit PWM (4095
>> levels of brightness)
>> This driver supports configuration using platform_data.
>>
>> Signed-off-by: Maximilian Güntner 
>> ---
>>  v3:
>>fixed warnings when running make C=1 CF=-D__CHECK_ENDIAN__:
>> * replaced u16* by __le16*
>>
>
> OK, replaced the old one in my tree.
>
> Thanks,
> -Bryan
>
--
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 06/15] clk: tegra: move fields to tegra_clk_pll_params

[Andrew Bresticker]

Hi Peter,

> @@ -1682,17 +1664,15 @@ struct clk *tegra_clk_register_pllc(const char *name, 
> const char *parent_name,
>  struct clk *tegra_clk_register_plle_tegra114(const char *name,
> const char *parent_name,
> void __iomem *clk_base, unsigned long flags,
> -   unsigned long fixed_rate,
> struct tegra_clk_pll_params *pll_params,
> -   struct tegra_clk_pll_freq_table *freq_table,
> spinlock_t *lock)
>  {
> struct tegra_clk_pll *pll;
> struct clk *clk;
> u32 val, val_aux;
>
> -   pll = _tegra_init_pll(clk_base, NULL, fixed_rate, pll_params,
> - TEGRA_PLL_HAS_LOCK_ENABLE, freq_table, lock);
> +   pll_params->flags = TEGRA_PLL_HAS_LOCK_ENABLE;

Why are we just overwriting the flags?  We pass in flags here:

> @@ -661,6 +685,9 @@ static struct tegra_clk_pll_params pll_e_params = {
> .lock_enable_bit_idx = PLLE_MISC_LOCK_ENABLE,
> .lock_delay = 300,
> .div_nmp = _nmp,
> +   .freq_table = pll_e_freq_table,
> +   .flags = TEGRA_PLL_FIXED,

TEGRA_PLL_FIXED doesn't actually make a difference in the
plle_tegra114 case, but it would be nice to be correct about setting
it.

Thanks,
Andrew
--
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] leds: Added driver for the NXP PCA9685 I2C chip

[Bryan Wu]

On Wed, Oct 16, 2013 at 6:09 PM, Maximilian Güntner
 wrote:
> The NXP PCA9685 supports 16 channels/leds using a 12-bit PWM (4095
> levels of brightness)
> This driver supports configuration using platform_data.
>
> Signed-off-by: Maximilian Güntner 
> ---
>  v3:
>fixed warnings when running make C=1 CF=-D__CHECK_ENDIAN__:
> * replaced u16* by __le16*
>

OK, replaced the old one in my tree.

Thanks,
-Bryan

>  v2:
>addresses bryan wu's comments:
> * removed/added some empty lines
>addresses peter meerwald's comments:
> * fixed typos
> * replaced/moved one if statement
> * replaced (1 << pca9685_ai) with bit(pca9685_ai)
>addresses jingoo han's comments:
> * added an empty line
> * sorted the header inclusions alphabetically
>
>  drivers/leds/Kconfig   |  10 ++
>  drivers/leds/Makefile  |   1 +
>  drivers/leds/leds-pca9685.c| 213 
> +
>  include/linux/platform_data/leds-pca9685.h |  35 +
>  4 files changed, 259 insertions(+)
>  create mode 100644 drivers/leds/leds-pca9685.c
>  create mode 100644 include/linux/platform_data/leds-pca9685.h
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 875bbe4..72156c1 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -300,6 +300,16 @@ config LEDS_PCA963X
>   LED driver chip accessed via the I2C bus. Supported
>   devices include PCA9633 and PCA9634
>
> +config LEDS_PCA9685
> +   tristate "LED support for PCA9685 I2C chip"
> +   depends on LEDS_CLASS
> +   depends on I2C
> +   help
> + This option enables support for LEDs connected to the PCA9685
> + LED driver chip accessed via the I2C bus.
> + The PCA9685 offers 12-bit PWM (4095 levels of brightness) on
> + 16 individual channels.
> +
>  config LEDS_WM831X_STATUS
> tristate "LED support for status LEDs on WM831x PMICs"
> depends on LEDS_CLASS
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index 8979b0b..3cd76db 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_LEDS_OT200)  += leds-ot200.o
>  obj-$(CONFIG_LEDS_FSG) += leds-fsg.o
>  obj-$(CONFIG_LEDS_PCA955X) += leds-pca955x.o
>  obj-$(CONFIG_LEDS_PCA963X) += leds-pca963x.o
> +obj-$(CONFIG_LEDS_PCA9685) += leds-pca9685.o
>  obj-$(CONFIG_LEDS_DA903X)  += leds-da903x.o
>  obj-$(CONFIG_LEDS_DA9052)  += leds-da9052.o
>  obj-$(CONFIG_LEDS_WM831X_STATUS)   += leds-wm831x-status.o
> diff --git a/drivers/leds/leds-pca9685.c b/drivers/leds/leds-pca9685.c
> new file mode 100644
> index 000..6e1ef3a
> --- /dev/null
> +++ b/drivers/leds/leds-pca9685.c
> @@ -0,0 +1,213 @@
> +/*
> + * Copyright 2013 Maximilian Güntner 
> + *
> + * This file is subject to the terms and conditions of version 2 of
> + * the GNU General Public License.  See the file COPYING in the main
> + * directory of this archive for more details.
> + *
> + * Based on leds-pca963x.c driver by
> + * Peter Meerwald 
> + *
> + * Driver for the NXP PCA9685 12-Bit PWM LED driver chip.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +/* Register Addresses */
> +#define PCA9685_MODE1 0x00
> +#define PCA9685_MODE2 0x01
> +#define PCA9685_LED0_ON_L 0x06
> +#define PCA9685_ALL_LED_ON_L 0xFA
> +
> +/* MODE1 Register */
> +#define PCA9685_ALLCALL 0x00
> +#define PCA9685_SLEEP   0x04
> +#define PCA9685_AI  0x05
> +
> +/* MODE2 Register */
> +#define PCA9685_INVRT   0x04
> +#define PCA9685_OUTDRV  0x02
> +
> +static const struct i2c_device_id pca9685_id[] = {
> +   { "pca9685", 0 },
> +   { }
> +};
> +MODULE_DEVICE_TABLE(i2c, pca9685_id);
> +
> +struct pca9685_led {
> +   struct i2c_client *client;
> +   struct work_struct work;
> +   u16 brightness;
> +   struct led_classdev led_cdev;
> +   int led_num; /* 0-15 */
> +   char name[32];
> +};
> +
> +static void pca9685_write_msg(struct i2c_client *client, u8 *buf, u8 len)
> +{
> +   struct i2c_msg msg = {
> +   .addr = client->addr,
> +   .flags = 0x00,
> +   .len = len,
> +   .buf = buf
> +   };
> +   i2c_transfer(client->adapter, , 1);
> +}
> +
> +static void pca9685_all_off(struct i2c_client *client)
> +{
> +   u8 i2c_buffer[5] = {PCA9685_ALL_LED_ON_L, 0x00, 0x00, 0x00, 0x10};
> +   pca9685_write_msg(client, i2c_buffer, 5);
> +}
> +
> +static void pca9685_led_work(struct work_struct *work)
> +{
> +   struct pca9685_led *pca9685;
> +   u8 i2c_buffer[5];
> +
> +   pca9685 = container_of(work, struct pca9685_led, work);
> +   i2c_buffer[0] = PCA9685_LED0_ON_L + 4 * pca9685->led_num;
> +   /*
> +* 4095 is the maximum brightness, so we set the ON 

Re: [PATCH 1/1] remove cpqarray from mainline kernel

[Jens Axboe]

On Thu, Oct 17 2013, Andrew Morton wrote:
> On Thu, 17 Oct 2013 12:52:26 -0500 Mike Miller  wrote:
> 
> > cpqarray hasn't been used in over 12 years. It's doubtful that anyone still
> > uses the board. It's time the driver was removed from the mainline kernel.
> > The only updates these days are minor and mostly done by people outside of 
> > HP.
> 
> It's amazing the weird stuff people get up to.  Perhaps we should disable
> it in config for a cycle or two, see if that flushes anyone out?

I think that would be prudent, you never know what people run...

-- 
Jens Axboe

--
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 v10 06/12] intel_mid: Refactored sfi_parse_devs() function

[David Cohen]

From: Kuppuswamy Sathyanarayanan 

SFI device_id[] table parsing code is duplicated in every SFI
device handler. This patch removes this code duplication, by
adding a seperate function get_device_id() to parse through the
device table. Also this patch moves the SPI, I2C, IPC info code from
sfi_parse_devs() to respective device handlers.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Signed-off-by: David Cohen 
---
 arch/x86/platform/intel-mid/intel-mid.c | 141 
 1 file changed, 71 insertions(+), 70 deletions(-)

diff --git a/arch/x86/platform/intel-mid/intel-mid.c 
b/arch/x86/platform/intel-mid/intel-mid.c
index 94689ac..d24c729 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -831,20 +831,15 @@ static void __init install_irq_resource(struct 
platform_device *pdev, int irq)
platform_device_add_resources(pdev, , 1);
 }
 
-static void __init sfi_handle_ipc_dev(struct sfi_device_table_entry *entry)
+static void __init sfi_handle_ipc_dev(struct sfi_device_table_entry *pentry,
+   struct devs_id *dev)
 {
-   const struct devs_id *dev = device_ids;
struct platform_device *pdev;
void *pdata = NULL;
 
-   while (dev->name[0]) {
-   if (dev->type == SFI_DEV_TYPE_IPC &&
-   !strncmp(dev->name, entry->name, SFI_NAME_LEN)) {
-   pdata = dev->get_platform_data(entry);
-   break;
-   }
-   dev++;
-   }
+   pr_debug("IPC bus, name = %16.16s, irq = 0x%2x\n",
+   pentry->name, pentry->irq);
+   pdata = dev->get_platform_data(pentry);
 
/*
 * On Medfield the platform device creation is handled by the MSIC
@@ -853,68 +848,94 @@ static void __init sfi_handle_ipc_dev(struct 
sfi_device_table_entry *entry)
if (intel_mid_has_msic())
return;
 
-   pdev = platform_device_alloc(entry->name, 0);
+   pdev = platform_device_alloc(pentry->name, 0);
if (pdev == NULL) {
pr_err("out of memory for SFI platform device '%s'.\n",
-   entry->name);
+   pentry->name);
return;
}
-   install_irq_resource(pdev, entry->irq);
+   install_irq_resource(pdev, pentry->irq);
 
pdev->dev.platform_data = pdata;
intel_scu_device_register(pdev);
 }
 
-static void __init sfi_handle_spi_dev(struct spi_board_info *spi_info)
+static void __init sfi_handle_spi_dev(struct sfi_device_table_entry *pentry,
+   struct devs_id *dev)
 {
-   const struct devs_id *dev = device_ids;
+   struct spi_board_info spi_info;
void *pdata = NULL;
 
-   while (dev->name[0]) {
-   if (dev->type == SFI_DEV_TYPE_SPI &&
-   !strncmp(dev->name, spi_info->modalias,
-   SFI_NAME_LEN)) {
-   pdata = dev->get_platform_data(spi_info);
-   break;
-   }
-   dev++;
-   }
-   spi_info->platform_data = pdata;
+   memset(_info, 0, sizeof(spi_info));
+   strncpy(spi_info.modalias, pentry->name, SFI_NAME_LEN);
+   spi_info.irq = ((pentry->irq == (u8)0xff) ? 0 : pentry->irq);
+   spi_info.bus_num = pentry->host_num;
+   spi_info.chip_select = pentry->addr;
+   spi_info.max_speed_hz = pentry->max_freq;
+   pr_debug("SPI bus=%d, name=%16.16s, irq=0x%2x, max_freq=%d, cs=%d\n",
+   spi_info.bus_num,
+   spi_info.modalias,
+   spi_info.irq,
+   spi_info.max_speed_hz,
+   spi_info.chip_select);
+
+   pdata = dev->get_platform_data(_info);
+
+   spi_info.platform_data = pdata;
if (dev->delay)
-   intel_scu_spi_device_register(spi_info);
+   intel_scu_spi_device_register(_info);
else
-   spi_register_board_info(spi_info, 1);
+   spi_register_board_info(_info, 1);
 }
 
-static void __init sfi_handle_i2c_dev(int bus, struct i2c_board_info *i2c_info)
+static void __init sfi_handle_i2c_dev(struct sfi_device_table_entry *pentry,
+   struct devs_id *dev)
 {
-   const struct devs_id *dev = device_ids;
+   struct i2c_board_info i2c_info;
void *pdata = NULL;
 
+   memset(_info, 0, sizeof(i2c_info));
+   strncpy(i2c_info.type, pentry->name, SFI_NAME_LEN);
+   i2c_info.irq = ((pentry->irq == (u8)0xff) ? 0 : pentry->irq);
+   i2c_info.addr = pentry->addr;
+   pr_debug("I2C bus = %d, name = %16.16s, irq = 0x%2x, addr = 0x%x\n",
+   pentry->host_num,
+   i2c_info.type,
+   i2c_info.irq,
+   i2c_info.addr);
+   pdata = dev->get_platform_data(_info);
+   i2c_info.platform_data = pdata;
+
+   if (dev->delay)
+   

[PATCH v10 02/12] mrst: Fixed indentation issues

[David Cohen]

From: Kuppuswamy Sathyanarayanan 

Fixed indentation issues reported by checkpatch script in
mrst related files.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Signed-off-by: David Cohen 
---
 arch/x86/platform/mrst/early_printk_mrst.c |  3 ++-
 arch/x86/platform/mrst/mrst.c  | 24 +---
 2 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/arch/x86/platform/mrst/early_printk_mrst.c 
b/arch/x86/platform/mrst/early_printk_mrst.c
index 95880f7..39ecc27 100644
--- a/arch/x86/platform/mrst/early_printk_mrst.c
+++ b/arch/x86/platform/mrst/early_printk_mrst.c
@@ -219,7 +219,8 @@ static void early_mrst_spi_putc(char c)
 }
 
 /* Early SPI only uses polling mode */
-static void early_mrst_spi_write(struct console *con, const char *str, 
unsigned n)
+static void early_mrst_spi_write(struct console *con, const char *str,
+   unsigned n)
 {
int i;
 
diff --git a/arch/x86/platform/mrst/mrst.c b/arch/x86/platform/mrst/mrst.c
index b9aeb54..235a742 100644
--- a/arch/x86/platform/mrst/mrst.c
+++ b/arch/x86/platform/mrst/mrst.c
@@ -131,7 +131,7 @@ struct sfi_timer_table_entry *sfi_get_mtmr(int hint)
int i;
if (hint < sfi_mtimer_num) {
if (!sfi_mtimer_usage[hint]) {
-   pr_debug("hint taken for timer %d irq %d\n",\
+   pr_debug("hint taken for timer %d irq %d\n",
hint, sfi_mtimer_array[hint].irq);
sfi_mtimer_usage[hint] = 1;
return _mtimer_array[hint];
@@ -679,14 +679,14 @@ static void *msic_thermal_platform_data(void *info)
 /* tc35876x DSI-LVDS bridge chip and panel platform data */
 static void *tc35876x_platform_data(void *data)
 {
-   static struct tc35876x_platform_data pdata;
+   static struct tc35876x_platform_data pdata;
 
-   /* gpio pins set to -1 will not be used by the driver */
-   pdata.gpio_bridge_reset = get_gpio_by_name("LCMB_RXEN");
-   pdata.gpio_panel_bl_en = get_gpio_by_name("6S6P_BL_EN");
-   pdata.gpio_panel_vadd = get_gpio_by_name("EN_VREG_LCD_V3P3");
+   /* gpio pins set to -1 will not be used by the driver */
+   pdata.gpio_bridge_reset = get_gpio_by_name("LCMB_RXEN");
+   pdata.gpio_panel_bl_en = get_gpio_by_name("6S6P_BL_EN");
+   pdata.gpio_panel_vadd = get_gpio_by_name("EN_VREG_LCD_V3P3");
 
-   return 
+   return 
 }
 
 static const struct devs_id __initconst device_ids[] = {
@@ -729,7 +729,7 @@ static int i2c_next_dev;
 
 static void __init intel_scu_device_register(struct platform_device *pdev)
 {
-   if(ipc_next_dev == MAX_IPCDEVS)
+   if (ipc_next_dev == MAX_IPCDEVS)
pr_err("too many SCU IPC devices");
else
ipc_devs[ipc_next_dev++] = pdev;
@@ -872,7 +872,8 @@ static void __init sfi_handle_spi_dev(struct spi_board_info 
*spi_info)
 
while (dev->name[0]) {
if (dev->type == SFI_DEV_TYPE_SPI &&
-   !strncmp(dev->name, spi_info->modalias, 
SFI_NAME_LEN)) {
+   !strncmp(dev->name, spi_info->modalias,
+   SFI_NAME_LEN)) {
pdata = dev->get_platform_data(spi_info);
break;
}
@@ -904,7 +905,7 @@ static void __init sfi_handle_i2c_dev(int bus, struct 
i2c_board_info *i2c_info)
intel_scu_i2c_device_register(bus, i2c_info);
else
i2c_register_board_info(bus, i2c_info, 1);
- }
+}
 
 
 static int __init sfi_parse_devs(struct sfi_table_header *table)
@@ -1034,7 +1035,8 @@ static int __init pb_keys_init(void)
num = sizeof(gpio_button) / sizeof(struct gpio_keys_button);
for (i = 0; i < num; i++) {
gb[i].gpio = get_gpio_by_name(gb[i].desc);
-   pr_debug("info[%2d]: name = %s, gpio = %d\n", i, gb[i].desc, 
gb[i].gpio);
+   pr_debug("info[%2d]: name = %s, gpio = %d\n", i, gb[i].desc,
+   gb[i].gpio);
if (gb[i].gpio == -1)
continue;
 
-- 
1.8.4.rc3

--
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 v10 03/12] intel_mid: Renamed *mrst* to *intel_mid*

[David Cohen]

From: Kuppuswamy Sathyanarayanan 

Following files contains code that is common to all intel mid
soc's. So renamed them as below.

mrst/mrst.c  -> intel-mid/intel-mid.c
mrst/vrtc.c  -> intel-mid/intel_mid_vrtc.c
mrst/early_printk_mrst.c -> intel-mid/intel_mid_vrtc.c
pci/mrst.c   -> pci/intel_mid_pci.c

Also, renamed the corresponding header files and made changes
to the driver files that included these header files.

To ensure that there are no functional changes, I have compared
the objdump of renamed files before and after rename and found
that the only difference is file name change.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Signed-off-by: David Cohen 
---
 arch/x86/include/asm/{mrst.h => intel-mid.h}  |  8 
 arch/x86/include/asm/{mrst-vrtc.h => intel_mid_vrtc.h}|  4 ++--
 arch/x86/kernel/apb_timer.c   |  2 +-
 arch/x86/kernel/early_printk.c|  2 +-
 arch/x86/kernel/rtc.c |  2 +-
 arch/x86/pci/Makefile |  2 +-
 arch/x86/pci/{mrst.c => intel_mid_pci.c}  |  2 +-
 arch/x86/platform/Makefile|  2 +-
 arch/x86/platform/intel-mid/Makefile  |  3 +++
 .../early_printk_intel_mid.c} |  4 ++--
 arch/x86/platform/{mrst/mrst.c => intel-mid/intel-mid.c}  | 11 ++-
 arch/x86/platform/{mrst/vrtc.c => intel-mid/intel_mid_vrtc.c} |  6 +++---
 arch/x86/platform/mrst/Makefile   |  3 ---
 drivers/gpu/drm/gma500/mdfld_dsi_output.h |  2 +-
 drivers/gpu/drm/gma500/oaktrail_device.c  |  2 +-
 drivers/gpu/drm/gma500/oaktrail_lvds.c|  2 +-
 drivers/platform/x86/intel_scu_ipc.c  |  2 +-
 drivers/rtc/rtc-mrst.c|  4 ++--
 drivers/watchdog/intel_scu_watchdog.c |  2 +-
 19 files changed, 33 insertions(+), 32 deletions(-)
 rename arch/x86/include/asm/{mrst.h => intel-mid.h} (93%)
 rename arch/x86/include/asm/{mrst-vrtc.h => intel_mid_vrtc.h} (81%)
 rename arch/x86/pci/{mrst.c => intel_mid_pci.c} (99%)
 create mode 100644 arch/x86/platform/intel-mid/Makefile
 rename arch/x86/platform/{mrst/early_printk_mrst.c => 
intel-mid/early_printk_intel_mid.c} (98%)
 rename arch/x86/platform/{mrst/mrst.c => intel-mid/intel-mid.c} (99%)
 rename arch/x86/platform/{mrst/vrtc.c => intel-mid/intel_mid_vrtc.c} (97%)
 delete mode 100644 arch/x86/platform/mrst/Makefile

diff --git a/arch/x86/include/asm/mrst.h b/arch/x86/include/asm/intel-mid.h
similarity index 93%
rename from arch/x86/include/asm/mrst.h
rename to arch/x86/include/asm/intel-mid.h
index fc18bf3..cc79a4f 100644
--- a/arch/x86/include/asm/mrst.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -1,5 +1,5 @@
 /*
- * mrst.h: Intel Moorestown platform specific setup code
+ * intel-mid.h: Intel MID specific setup code
  *
  * (C) Copyright 2009 Intel Corporation
  *
@@ -8,8 +8,8 @@
  * as published by the Free Software Foundation; version 2
  * of the License.
  */
-#ifndef _ASM_X86_MRST_H
-#define _ASM_X86_MRST_H
+#ifndef _ASM_X86_INTEL_MID_H
+#define _ASM_X86_INTEL_MID_H
 
 #include 
 
@@ -78,4 +78,4 @@ extern void intel_scu_devices_destroy(void);
 
 extern void mrst_rtc_init(void);
 
-#endif /* _ASM_X86_MRST_H */
+#endif /* _ASM_X86_INTEL_MID_H */
diff --git a/arch/x86/include/asm/mrst-vrtc.h 
b/arch/x86/include/asm/intel_mid_vrtc.h
similarity index 81%
rename from arch/x86/include/asm/mrst-vrtc.h
rename to arch/x86/include/asm/intel_mid_vrtc.h
index 1e69a75..86ff468 100644
--- a/arch/x86/include/asm/mrst-vrtc.h
+++ b/arch/x86/include/asm/intel_mid_vrtc.h
@@ -1,5 +1,5 @@
-#ifndef _MRST_VRTC_H
-#define _MRST_VRTC_H
+#ifndef _INTEL_MID_VRTC_H
+#define _INTEL_MID_VRTC_H
 
 extern unsigned char vrtc_cmos_read(unsigned char reg);
 extern void vrtc_cmos_write(unsigned char val, unsigned char reg);
diff --git a/arch/x86/kernel/apb_timer.c b/arch/x86/kernel/apb_timer.c
index c9876ef..9154836 100644
--- a/arch/x86/kernel/apb_timer.c
+++ b/arch/x86/kernel/apb_timer.c
@@ -40,7 +40,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #define APBT_CLOCKEVENT_RATING 110
diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
index d15f575..38ca398 100644
--- a/arch/x86/kernel/early_printk.c
+++ b/arch/x86/kernel/early_printk.c
@@ -14,7 +14,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c
index 0aa2939..a1b52fe 100644
--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #ifdef CONFIG_X86_32
diff --git a/arch/x86/pci/Makefile b/arch/x86/pci/Makefile
index ee0af58..e063eed 100644
--- 

Re: [PATCH v4 05/15] clk: tegra: move some PLLC and PLLXC init to clk-pll.c

[Andrew Bresticker]

Hi Peter,

> +   val = readl_relaxed(clk_base + pll_params->base_reg);
> +   val_iddq = readl_relaxed(clk_base + pll_params->iddq_reg);
> +
> +   if (val & BIT(30))

BIT(30) -> PLL_BASE_ENABLE?

> +   WARN_ON(val_iddq & BIT(pll_params->iddq_bit_idx));
> +   else {
> +   val_iddq |= BIT(pll_params->iddq_bit_idx);
> +   writel_relaxed(val_iddq, clk_base + pll_params->iddq_reg);
> +   }

Thanks,
Andrew
--
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 v10 05/12] intel_mid: Renamed *mrst* to *intel_mid*

[David Cohen]

From: Kuppuswamy Sathyanarayanan 

mrst is used as common name to represent all intel_mid type
soc's. But moorsetwon is just one of the intel_mid soc. So
renamed them to use intel_mid.

This patch mainly renames the variables and related
functions that uses *mrst* prefix with *intel_mid*.

To ensure that there are no functional changes, I have compared
the objdump of related files before and after rename and found
the only difference is symbol and name changes.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Signed-off-by: David Cohen 
---
 Documentation/kernel-parameters.txt|   6 +-
 arch/x86/include/asm/intel-mid.h   |  26 ++---
 arch/x86/include/asm/setup.h   |   4 +-
 arch/x86/include/uapi/asm/bootparam.h  |   2 +-
 arch/x86/kernel/apb_timer.c|   8 +-
 arch/x86/kernel/head32.c   |   4 +-
 arch/x86/kernel/rtc.c  |   2 +-
 arch/x86/pci/intel_mid_pci.c   |  12 +--
 .../platform/intel-mid/early_printk_intel_mid.c|   2 +-
 arch/x86/platform/intel-mid/intel-mid.c| 109 ++---
 arch/x86/platform/intel-mid/intel_mid_vrtc.c   |   8 +-
 drivers/platform/x86/intel_scu_ipc.c   |   2 +-
 drivers/watchdog/intel_scu_watchdog.c  |   2 +-
 13 files changed, 93 insertions(+), 94 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index fcbb736..dfaeb0c 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3471,11 +3471,11 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
default x2apic cluster mode on platforms
supporting x2apic.
 
-   x86_mrst_timer= [X86-32,APBT]
-   Choose timer option for x86 Moorestown MID platform.
+   x86_intel_mid_timer= [X86-32,APBT]
+   Choose timer option for x86 Intel MID platform.
Two valid options are apbt timer only and lapic timer
plus one apbt timer for broadcast timer.
-   x86_mrst_timer=apbt_only | lapic_and_apbt
+   x86_intel_mid_timer=apbt_only | lapic_and_apbt
 
xen_emul_unplug=[HW,X86,XEN]
Unplug Xen emulated devices
diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index cc79a4f..beb7a5f 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -13,7 +13,7 @@
 
 #include 
 
-extern int pci_mrst_init(void);
+extern int intel_mid_pci_init(void);
 extern int __init sfi_parse_mrtc(struct sfi_table_header *table);
 extern int sfi_mrtc_num;
 extern struct sfi_rtc_table_entry sfi_mrtc_array[];
@@ -25,33 +25,33 @@ extern struct sfi_rtc_table_entry sfi_mrtc_array[];
  * we treat Medfield/Penwell as a variant of Moorestown. Penwell can be
  * identified via MSRs.
  */
-enum mrst_cpu_type {
+enum intel_mid_cpu_type {
/* 1 was Moorestown */
-   MRST_CPU_CHIP_PENWELL = 2,
+   INTEL_MID_CPU_CHIP_PENWELL = 2,
 };
 
-extern enum mrst_cpu_type __mrst_cpu_chip;
+extern enum intel_mid_cpu_type __intel_mid_cpu_chip;
 
 #ifdef CONFIG_X86_INTEL_MID
 
-static inline enum mrst_cpu_type mrst_identify_cpu(void)
+static inline enum intel_mid_cpu_type intel_mid_identify_cpu(void)
 {
-   return __mrst_cpu_chip;
+   return __intel_mid_cpu_chip;
 }
 
 #else /* !CONFIG_X86_INTEL_MID */
 
-#define mrst_identify_cpu()(0)
+#define intel_mid_identify_cpu()(0)
 
 #endif /* !CONFIG_X86_INTEL_MID */
 
-enum mrst_timer_options {
-   MRST_TIMER_DEFAULT,
-   MRST_TIMER_APBT_ONLY,
-   MRST_TIMER_LAPIC_APBT,
+enum intel_mid_timer_options {
+   INTEL_MID_TIMER_DEFAULT,
+   INTEL_MID_TIMER_APBT_ONLY,
+   INTEL_MID_TIMER_LAPIC_APBT,
 };
 
-extern enum mrst_timer_options mrst_timer_options;
+extern enum intel_mid_timer_options intel_mid_timer_options;
 
 /*
  * Penwell uses spread spectrum clock, so the freq number is not exactly
@@ -76,6 +76,6 @@ extern void intel_scu_devices_destroy(void);
 #define MRST_VRTC_MAP_SZ   (1024)
 /*#define MRST_VRTC_PGOFFSET   (0xc00) */
 
-extern void mrst_rtc_init(void);
+extern void intel_mid_rtc_init(void);
 
 #endif /* _ASM_X86_INTEL_MID_H */
diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index 3475554..59bcf4e 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -51,9 +51,9 @@ extern void i386_reserve_resources(void);
 extern void setup_default_timer_irq(void);
 
 #ifdef CONFIG_X86_INTEL_MID
-extern void x86_mrst_early_setup(void);
+extern void x86_intel_mid_early_setup(void);
 #else
-static inline void x86_mrst_early_setup(void) { }
+static inline void x86_intel_mid_early_setup(void) { }
 #endif
 
 #ifdef CONFIG_X86_INTEL_CE
diff --git 

[PATCH v10 04/12] pci: intel_mid: return true/false in function returning bool

[David Cohen]

From: Fengguang Wu 

Function 'type1_access_ok' should return bool value, not 0/1.
This patch changes 'return 0/1' to 'return false/true'.

Cc: Kuppuswamy Sathyanarayanan 
Cc: H. Peter Anvin 
Cc: David Cohen 
Signed-off-by: Fengguang Wu 
---
 arch/x86/pci/intel_mid_pci.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
index f8715f7..c5ca5b9 100644
--- a/arch/x86/pci/intel_mid_pci.c
+++ b/arch/x86/pci/intel_mid_pci.c
@@ -150,12 +150,12 @@ static bool type1_access_ok(unsigned int bus, unsigned 
int devfn, int reg)
 * shim. Therefore, use the header type in shim instead.
 */
if (reg >= 0x100 || reg == PCI_STATUS || reg == PCI_HEADER_TYPE)
-   return 0;
+   return false;
if (bus == 0 && (devfn == PCI_DEVFN(2, 0)
|| devfn == PCI_DEVFN(0, 0)
|| devfn == PCI_DEVFN(3, 0)))
-   return 1;
-   return 0; /* Langwell on others */
+   return true;
+   return false; /* Langwell on others */
 }
 
 static int pci_read(struct pci_bus *bus, unsigned int devfn, int where,
-- 
1.8.4.rc3

--
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 v10 00/12] rework arch/x86/platform/[mrst => intel-mid]

[David Cohen]

This patch set does initial rework from arch/x86/platform/mrst to
arch/x86/platform/intel-mid.
These changes are necessary to update the obsolete Intel Atom Moorestown code
to support the newer Atom processors of this family (called 'intel-mid'). 

Change from v9 to v10:
 - Improved patch title of one coccinelle warning fix.
 - Removed one non-functional patch fixing coccinelle warning.
 - Squashed non-functional patch which fixed compilation warning on the deleted
   mrst.c file.

There is no function change in the end.
---

David Cohen (3):
  intel-mid: sfi: allow struct devs_id.get_platform_data to be NULL
  x86: intel-mid: add section for sfi device table
  intel_mid: move board related codes to their own platform_.*
files

Fengguang Wu (1):
  pci: intel_mid: return true/false in function returning bool

Kuppuswamy Sathyanarayanan (8):
  mrst: Fixed printk/pr_* related issues
  mrst: Fixed indentation issues
  intel_mid: Renamed *mrst* to *intel_mid*
  intel_mid: Renamed *mrst* to *intel_mid*
  intel_mid: Refactored sfi_parse_devs() function
  intel_mid: Added custom device_handler support
  intel_mid: Added custom handler for ipc devices
  intel_mid: Moved SFI related code to sfi.c

 Documentation/kernel-parameters.txt|6 +-
 arch/x86/include/asm/intel-mid.h   |  113 +++
 .../include/asm/{mrst-vrtc.h => intel_mid_vrtc.h}  |4 +-
 arch/x86/include/asm/mrst.h|   81 --
 arch/x86/include/asm/setup.h   |4 +-
 arch/x86/include/uapi/asm/bootparam.h  |2 +-
 arch/x86/kernel/apb_timer.c|   10 +-
 arch/x86/kernel/early_printk.c |2 +-
 arch/x86/kernel/head32.c   |4 +-
 arch/x86/kernel/rtc.c  |4 +-
 arch/x86/kernel/vmlinux.lds.S  |9 +
 arch/x86/pci/Makefile  |2 +-
 arch/x86/pci/{mrst.c => intel_mid_pci.c}   |   20 +-
 arch/x86/platform/Makefile |2 +-
 arch/x86/platform/intel-mid/Makefile   |7 +
 arch/x86/platform/intel-mid/device_libs/Makefile   |   22 +
 .../intel-mid/device_libs/platform_bma023.c|   20 +
 .../intel-mid/device_libs/platform_emc1403.c   |   41 +
 .../intel-mid/device_libs/platform_gpio_keys.c |   83 ++
 .../platform/intel-mid/device_libs/platform_ipc.c  |   68 ++
 .../platform/intel-mid/device_libs/platform_ipc.h  |   17 +
 .../intel-mid/device_libs/platform_lis331.c|   39 +
 .../intel-mid/device_libs/platform_max3111.c   |   35 +
 .../intel-mid/device_libs/platform_max7315.c   |   79 ++
 .../intel-mid/device_libs/platform_mpu3050.c   |   36 +
 .../platform/intel-mid/device_libs/platform_msic.c |   87 ++
 .../platform/intel-mid/device_libs/platform_msic.h |   19 +
 .../intel-mid/device_libs/platform_msic_audio.c|   47 +
 .../intel-mid/device_libs/platform_msic_battery.c  |   37 +
 .../intel-mid/device_libs/platform_msic_gpio.c |   48 +
 .../intel-mid/device_libs/platform_msic_ocd.c  |   49 +
 .../device_libs/platform_msic_power_btn.c  |   36 +
 .../intel-mid/device_libs/platform_msic_thermal.c  |   37 +
 .../intel-mid/device_libs/platform_pmic_gpio.c |   54 +
 .../intel-mid/device_libs/platform_tc35876x.c  |   36 +
 .../intel-mid/device_libs/platform_tca6416.c   |   57 ++
 .../early_printk_intel_mid.c}  |   11 +-
 arch/x86/platform/intel-mid/intel-mid.c|  213 
 .../{mrst/vrtc.c => intel-mid/intel_mid_vrtc.c}|   19 +-
 arch/x86/platform/intel-mid/sfi.c  |  488 +
 arch/x86/platform/mrst/Makefile|3 -
 arch/x86/platform/mrst/mrst.c  | 1052 
 drivers/gpu/drm/gma500/mdfld_dsi_output.h  |2 +-
 drivers/gpu/drm/gma500/oaktrail_device.c   |2 +-
 drivers/gpu/drm/gma500/oaktrail_lvds.c |2 +-
 drivers/platform/x86/intel_scu_ipc.c   |4 +-
 drivers/rtc/rtc-mrst.c |4 +-
 drivers/watchdog/intel_scu_watchdog.c  |4 +-
 include/linux/sfi.h|3 +
 49 files changed, 1834 insertions(+), 1190 deletions(-)
 create mode 100644 arch/x86/include/asm/intel-mid.h
 rename arch/x86/include/asm/{mrst-vrtc.h => intel_mid_vrtc.h} (81%)
 delete mode 100644 arch/x86/include/asm/mrst.h
 rename arch/x86/pci/{mrst.c => intel_mid_pci.c} (96%)
 create mode 100644 arch/x86/platform/intel-mid/Makefile
 create mode 100644 arch/x86/platform/intel-mid/device_libs/Makefile
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_bma023.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_emc1403.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_gpio_keys.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_ipc.c
 create mode 100644 

helloo

[Alina Tekere]

hello,
how are you doing,? my name is Alina, please i know this mail will look strange 
to you
but please i have a very important issue to discuss with you, please its very 
important, reply me back so that i will
tell you more about it
i will be waiting for your reply soon
yours faithfully,

Alina

--
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 v10 11/12] x86: intel-mid: add section for sfi device table

[David Cohen]

When Intel mid uses SFI table to enumerate devices, it requires an extra
device table with further information about how to probe such devices.

This patch creates a section where the device table will stay if
CONFIG_X86_INTEL_MID is selected.

Signed-off-by: David Cohen 
---
 arch/x86/kernel/vmlinux.lds.S | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 10c4f30..da6b35a 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -199,6 +199,15 @@ SECTIONS
__x86_cpu_dev_end = .;
}
 
+#ifdef CONFIG_X86_INTEL_MID
+   .x86_intel_mid_dev.init : AT(ADDR(.x86_intel_mid_dev.init) - \
+   LOAD_OFFSET) {
+   __x86_intel_mid_dev_start = .;
+   *(.x86_intel_mid_dev.init)
+   __x86_intel_mid_dev_end = .;
+   }
+#endif
+
/*
 * start address and size of operations which during runtime
 * can be patched with virtualization friendly instructions or
-- 
1.8.4.rc3

--
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 v10 07/12] intel_mid: Added custom device_handler support

[David Cohen]

From: Kuppuswamy Sathyanarayanan 

This patch provides a means to add custom handler for
SFI devices. If you set device_handler as NULL in
device_id table standard SFI device handler will be used.
If its not NULL custom handler will be called.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Signed-off-by: David Cohen 
---
 arch/x86/platform/intel-mid/intel-mid.c | 74 ++---
 1 file changed, 40 insertions(+), 34 deletions(-)

diff --git a/arch/x86/platform/intel-mid/intel-mid.c 
b/arch/x86/platform/intel-mid/intel-mid.c
index d24c729..7bfd784 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -396,6 +396,9 @@ struct devs_id {
u8 type;
u8 delay;
void *(*get_platform_data)(void *info);
+   /* Custom handler for devices */
+   void (*device_handler)(struct sfi_device_table_entry *pentry,
+   struct devs_id *dev);
 };
 
 /* the offset for the mapping of global gpio pin to irq */
@@ -690,28 +693,27 @@ static void *tc35876x_platform_data(void *data)
 }
 
 static const struct devs_id __initconst device_ids[] = {
-   {"bma023", SFI_DEV_TYPE_I2C, 1, _platform_data},
-   {"pmic_gpio", SFI_DEV_TYPE_SPI, 1, _gpio_platform_data},
-   {"pmic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data},
-   {"spi_max3111", SFI_DEV_TYPE_SPI, 0, _platform_data},
-   {"i2c_max7315", SFI_DEV_TYPE_I2C, 1, _platform_data},
-   {"i2c_max7315_2", SFI_DEV_TYPE_I2C, 1, _platform_data},
-   {"tca6416", SFI_DEV_TYPE_I2C, 1, _platform_data},
-   {"emc1403", SFI_DEV_TYPE_I2C, 1, _platform_data},
-   {"i2c_accel", SFI_DEV_TYPE_I2C, 0, _platform_data},
-   {"pmic_audio", SFI_DEV_TYPE_IPC, 1, _platform_data},
-   {"mpu3050", SFI_DEV_TYPE_I2C, 1, _platform_data},
-   {"i2c_disp_brig", SFI_DEV_TYPE_I2C, 0, _platform_data},
+   {"bma023", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
+   {"pmic_gpio", SFI_DEV_TYPE_SPI, 1, _gpio_platform_data, NULL},
+   {"pmic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data, NULL},
+   {"spi_max3111", SFI_DEV_TYPE_SPI, 0, _platform_data, NULL},
+   {"i2c_max7315", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
+   {"i2c_max7315_2", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
+   {"tca6416", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
+   {"emc1403", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
+   {"i2c_accel", SFI_DEV_TYPE_I2C, 0, _platform_data, NULL},
+   {"pmic_audio", SFI_DEV_TYPE_IPC, 1, _platform_data, NULL},
+   {"mpu3050", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
+   {"i2c_disp_brig", SFI_DEV_TYPE_I2C, 0, _platform_data, NULL},
 
/* MSIC subdevices */
-   {"msic_battery", SFI_DEV_TYPE_IPC, 1, _battery_platform_data},
-   {"msic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data},
-   {"msic_audio", SFI_DEV_TYPE_IPC, 1, _audio_platform_data},
-   {"msic_power_btn", SFI_DEV_TYPE_IPC, 1, _power_btn_platform_data},
-   {"msic_ocd", SFI_DEV_TYPE_IPC, 1, _ocd_platform_data},
-   {"msic_thermal", SFI_DEV_TYPE_IPC, 1, _thermal_platform_data},
-
-   {},
+   {"msic_battery", SFI_DEV_TYPE_IPC, 1, _battery_platform_data, 
NULL},
+   {"msic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data, NULL},
+   {"msic_audio", SFI_DEV_TYPE_IPC, 1, _audio_platform_data, NULL},
+   {"msic_power_btn", SFI_DEV_TYPE_IPC, 1, _power_btn_platform_data, 
NULL},
+   {"msic_ocd", SFI_DEV_TYPE_IPC, 1, _ocd_platform_data, NULL},
+   {"msic_thermal", SFI_DEV_TYPE_IPC, 1, _thermal_platform_data, 
NULL},
+   { 0 }
 };
 
 #define MAX_IPCDEVS24
@@ -965,20 +967,24 @@ static int __init sfi_parse_devs(struct sfi_table_header 
*table)
if ((dev == NULL) || (dev->get_platform_data == NULL))
continue;
 
-   switch (pentry->type) {
-   case SFI_DEV_TYPE_IPC:
-   sfi_handle_ipc_dev(pentry, dev);
-   break;
-   case SFI_DEV_TYPE_SPI:
-   sfi_handle_spi_dev(pentry, dev);
-   break;
-   case SFI_DEV_TYPE_I2C:
-   sfi_handle_i2c_dev(pentry, dev);
-   break;
-   case SFI_DEV_TYPE_UART:
-   case SFI_DEV_TYPE_HSI:
-   default:
-   ;
+   if (dev->device_handler) {
+   dev->device_handler(pentry, dev);
+   } else {
+   switch (pentry->type) {
+   case SFI_DEV_TYPE_IPC:
+   sfi_handle_ipc_dev(pentry, dev);
+   break;
+   case SFI_DEV_TYPE_SPI:
+   sfi_handle_spi_dev(pentry, dev);
+   break;
+   case SFI_DEV_TYPE_I2C:
+   sfi_handle_i2c_dev(pentry, dev);
+ 

[PATCH v10 08/12] intel_mid: Added custom handler for ipc devices

[David Cohen]

From: Kuppuswamy Sathyanarayanan 

Added a custom handler for medfield based ipc devices and
moved devs_id structure defintion to header file.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Signed-off-by: David Cohen 
---
 arch/x86/include/asm/intel-mid.h| 15 ++
 arch/x86/platform/intel-mid/intel-mid.c | 82 -
 2 files changed, 66 insertions(+), 31 deletions(-)

diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index beb7a5f..ad236ae 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -19,6 +19,21 @@ extern int sfi_mrtc_num;
 extern struct sfi_rtc_table_entry sfi_mrtc_array[];
 
 /*
+ * Here defines the array of devices platform data that IAFW would export
+ * through SFI "DEVS" table, we use name and type to match the device and
+ * its platform data.
+ */
+struct devs_id {
+   char name[SFI_NAME_LEN + 1];
+   u8 type;
+   u8 delay;
+   void *(*get_platform_data)(void *info);
+   /* Custom handler for devices */
+   void (*device_handler)(struct sfi_device_table_entry *pentry,
+   struct devs_id *dev);
+};
+
+/*
  * Medfield is the follow-up of Moorestown, it combines two chip solution into
  * one. Other than that it also added always-on and constant tsc and lapic
  * timers. Medfield is the platform name, and the chip name is called Penwell
diff --git a/arch/x86/platform/intel-mid/intel-mid.c 
b/arch/x86/platform/intel-mid/intel-mid.c
index 7bfd784..40a3ff8 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -78,6 +78,8 @@ int sfi_mtimer_num;
 struct sfi_rtc_table_entry sfi_mrtc_array[SFI_MRTC_MAX];
 EXPORT_SYMBOL_GPL(sfi_mrtc_array);
 int sfi_mrtc_num;
+static void __init ipc_device_handler(struct sfi_device_table_entry *pentry,
+   struct devs_id *dev);
 
 static void intel_mid_power_off(void)
 {
@@ -386,21 +388,6 @@ static int get_gpio_by_name(const char *name)
return -1;
 }
 
-/*
- * Here defines the array of devices platform data that IAFW would export
- * through SFI "DEVS" table, we use name and type to match the device and
- * its platform data.
- */
-struct devs_id {
-   char name[SFI_NAME_LEN + 1];
-   u8 type;
-   u8 delay;
-   void *(*get_platform_data)(void *info);
-   /* Custom handler for devices */
-   void (*device_handler)(struct sfi_device_table_entry *pentry,
-   struct devs_id *dev);
-};
-
 /* the offset for the mapping of global gpio pin to irq */
 #define INTEL_MID_IRQ_OFFSET 0x100
 
@@ -695,24 +682,24 @@ static void *tc35876x_platform_data(void *data)
 static const struct devs_id __initconst device_ids[] = {
{"bma023", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"pmic_gpio", SFI_DEV_TYPE_SPI, 1, _gpio_platform_data, NULL},
-   {"pmic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data, NULL},
+   {"pmic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data, 
_device_handler},
{"spi_max3111", SFI_DEV_TYPE_SPI, 0, _platform_data, NULL},
{"i2c_max7315", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"i2c_max7315_2", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"tca6416", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"emc1403", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"i2c_accel", SFI_DEV_TYPE_I2C, 0, _platform_data, NULL},
-   {"pmic_audio", SFI_DEV_TYPE_IPC, 1, _platform_data, NULL},
+   {"pmic_audio", SFI_DEV_TYPE_IPC, 1, _platform_data, 
_device_handler},
{"mpu3050", SFI_DEV_TYPE_I2C, 1, _platform_data, NULL},
{"i2c_disp_brig", SFI_DEV_TYPE_I2C, 0, _platform_data, NULL},
 
/* MSIC subdevices */
-   {"msic_battery", SFI_DEV_TYPE_IPC, 1, _battery_platform_data, 
NULL},
-   {"msic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data, NULL},
-   {"msic_audio", SFI_DEV_TYPE_IPC, 1, _audio_platform_data, NULL},
-   {"msic_power_btn", SFI_DEV_TYPE_IPC, 1, _power_btn_platform_data, 
NULL},
-   {"msic_ocd", SFI_DEV_TYPE_IPC, 1, _ocd_platform_data, NULL},
-   {"msic_thermal", SFI_DEV_TYPE_IPC, 1, _thermal_platform_data, 
NULL},
+   {"msic_battery", SFI_DEV_TYPE_IPC, 1, _battery_platform_data, 
_device_handler},
+   {"msic_gpio", SFI_DEV_TYPE_IPC, 1, _gpio_platform_data, 
_device_handler},
+   {"msic_audio", SFI_DEV_TYPE_IPC, 1, _audio_platform_data, 
_device_handler},
+   {"msic_power_btn", SFI_DEV_TYPE_IPC, 1, _power_btn_platform_data, 
_device_handler},
+   {"msic_ocd", SFI_DEV_TYPE_IPC, 1, _ocd_platform_data, 
_device_handler},
+   {"msic_thermal", SFI_DEV_TYPE_IPC, 1, _thermal_platform_data, 
_device_handler},
{ 0 }
 };
 
@@ -843,13 +830,6 @@ static void __init sfi_handle_ipc_dev(struct 
sfi_device_table_entry *pentry,
pentry->name, pentry->irq);
pdata = dev->get_platform_data(pentry);
 
-   /*
-* On Medfield the 

[PATCH v10 12/12] intel_mid: move board related codes to their own platform_.* files

[David Cohen]

As Intel rolling out more SoC's after Moorestown, we need to
re-structure the code in a way that is backward compatible and easy to
expand. This patch implements a flexible way to support multiple boards
and devices.

This patch does not add any new functional support. It just refactors
the existing code to increase the modularity and decrease the code
duplication for supporting multiple soc's and boards.

Currently intel-mid.c has both board and soc related code in one file.
This patch moves the board related code to new files and let linker
script to create SFI devite table following this:

1. Move the SFI device specific code to
   arch/x86/platform/intel-mid/device-libs/platform_.*
   A new device file is added for every supported device. This code will
   get conditionally compiled by using corresponding device driver
   CONFIG option.

2. Move the device_ids location to .x86_intel_mid_dev.init section by
   using new sfi_device() macro.

This patch was based on previous code from Sathyanarayanan Kuppuswamy.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Signed-off-by: David Cohen 
---
 arch/x86/include/asm/intel-mid.h   |  16 +
 arch/x86/platform/intel-mid/Makefile   |   8 +-
 arch/x86/platform/intel-mid/device_libs/Makefile   |  22 ++
 .../intel-mid/device_libs/platform_bma023.c|  20 +
 .../intel-mid/device_libs/platform_emc1403.c   |  41 ++
 .../intel-mid/device_libs/platform_gpio_keys.c |  83 
 .../platform/intel-mid/device_libs/platform_ipc.c  |  68 
 .../platform/intel-mid/device_libs/platform_ipc.h  |  17 +
 .../intel-mid/device_libs/platform_lis331.c|  39 ++
 .../intel-mid/device_libs/platform_max3111.c   |  35 ++
 .../intel-mid/device_libs/platform_max7315.c   |  79 
 .../intel-mid/device_libs/platform_mpu3050.c   |  36 ++
 .../platform/intel-mid/device_libs/platform_msic.c |  87 +
 .../platform/intel-mid/device_libs/platform_msic.h |  19 +
 .../intel-mid/device_libs/platform_msic_audio.c|  47 +++
 .../intel-mid/device_libs/platform_msic_battery.c  |  37 ++
 .../intel-mid/device_libs/platform_msic_gpio.c |  48 +++
 .../intel-mid/device_libs/platform_msic_ocd.c  |  49 +++
 .../device_libs/platform_msic_power_btn.c  |  36 ++
 .../intel-mid/device_libs/platform_msic_thermal.c  |  37 ++
 .../intel-mid/device_libs/platform_pmic_gpio.c |  54 +++
 .../intel-mid/device_libs/platform_tc35876x.c  |  36 ++
 .../intel-mid/device_libs/platform_tca6416.c   |  57 +++
 arch/x86/platform/intel-mid/intel-mid.c| 419 -
 arch/x86/platform/intel-mid/sfi.c  |  14 +-
 include/linux/sfi.h|   3 +
 26 files changed, 978 insertions(+), 429 deletions(-)
 create mode 100644 arch/x86/platform/intel-mid/device_libs/Makefile
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_bma023.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_emc1403.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_gpio_keys.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_ipc.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_ipc.h
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_lis331.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_max3111.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_max7315.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_mpu3050.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_msic.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_msic.h
 create mode 100644 
arch/x86/platform/intel-mid/device_libs/platform_msic_audio.c
 create mode 100644 
arch/x86/platform/intel-mid/device_libs/platform_msic_battery.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_msic_gpio.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_msic_ocd.c
 create mode 100644 
arch/x86/platform/intel-mid/device_libs/platform_msic_power_btn.c
 create mode 100644 
arch/x86/platform/intel-mid/device_libs/platform_msic_thermal.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_pmic_gpio.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_tc35876x.c
 create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_tca6416.c

diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index 3b0e7a7..459769d 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -12,8 +12,11 @@
 #define _ASM_X86_INTEL_MID_H
 
 #include 
+#include 
 
 extern int intel_mid_pci_init(void);
+extern int get_gpio_by_name(const char *name);
+extern void intel_scu_device_register(struct platform_device *pdev);
 extern int __init sfi_parse_mrtc(struct sfi_table_header *table);
 extern int __init sfi_parse_mtmr(struct sfi_table_header *table);
 

[PATCH v10 09/12] intel_mid: Moved SFI related code to sfi.c

[David Cohen]

From: Kuppuswamy Sathyanarayanan 

Moved SFI specific parsing/handling code to sfi.c. This will enable us
to reuse our intel-mid code for platforms that supports firmware
interfaces other than SFI (like ACPI).

Signed-off-by: Kuppuswamy Sathyanarayanan 

Signed-off-by: David Cohen 
---
 arch/x86/include/asm/intel-mid.h|   1 +
 arch/x86/platform/intel-mid/Makefile|   2 +
 arch/x86/platform/intel-mid/intel-mid.c | 451 +
 arch/x86/platform/intel-mid/sfi.c   | 485 
 4 files changed, 489 insertions(+), 450 deletions(-)
 create mode 100644 arch/x86/platform/intel-mid/sfi.c

diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index ad236ae..3b0e7a7 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -15,6 +15,7 @@
 
 extern int intel_mid_pci_init(void);
 extern int __init sfi_parse_mrtc(struct sfi_table_header *table);
+extern int __init sfi_parse_mtmr(struct sfi_table_header *table);
 extern int sfi_mrtc_num;
 extern struct sfi_rtc_table_entry sfi_mrtc_array[];
 
diff --git a/arch/x86/platform/intel-mid/Makefile 
b/arch/x86/platform/intel-mid/Makefile
index de29635..b11e5b2 100644
--- a/arch/x86/platform/intel-mid/Makefile
+++ b/arch/x86/platform/intel-mid/Makefile
@@ -1,3 +1,5 @@
 obj-$(CONFIG_X86_INTEL_MID) += intel-mid.o
 obj-$(CONFIG_X86_INTEL_MID)+= intel_mid_vrtc.o
 obj-$(CONFIG_EARLY_PRINTK_INTEL_MID)   += early_printk_intel_mid.o
+# SFI specific code
+obj-$(CONFIG_SFI) += sfi.o
diff --git a/arch/x86/platform/intel-mid/intel-mid.c 
b/arch/x86/platform/intel-mid/intel-mid.c
index 40a3ff8..4091569 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -18,19 +18,9 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
 
 #include 
 #include 
@@ -68,19 +58,11 @@
 
 enum intel_mid_timer_options intel_mid_timer_options;
 
-static u32 sfi_mtimer_usage[SFI_MTMR_MAX_NUM];
-static struct sfi_timer_table_entry sfi_mtimer_array[SFI_MTMR_MAX_NUM];
 enum intel_mid_cpu_type __intel_mid_cpu_chip;
 EXPORT_SYMBOL_GPL(__intel_mid_cpu_chip);
 
-int sfi_mtimer_num;
-
-struct sfi_rtc_table_entry sfi_mrtc_array[SFI_MRTC_MAX];
-EXPORT_SYMBOL_GPL(sfi_mrtc_array);
-int sfi_mrtc_num;
 static void __init ipc_device_handler(struct sfi_device_table_entry *pentry,
struct devs_id *dev);
-
 static void intel_mid_power_off(void)
 {
 }
@@ -90,114 +72,6 @@ static void intel_mid_reboot(void)
intel_scu_ipc_simple_command(IPCMSG_COLD_BOOT, 0);
 }
 
-/* parse all the mtimer info to a static mtimer array */
-static int __init sfi_parse_mtmr(struct sfi_table_header *table)
-{
-   struct sfi_table_simple *sb;
-   struct sfi_timer_table_entry *pentry;
-   struct mpc_intsrc mp_irq;
-   int totallen;
-
-   sb = (struct sfi_table_simple *)table;
-   if (!sfi_mtimer_num) {
-   sfi_mtimer_num = SFI_GET_NUM_ENTRIES(sb,
-   struct sfi_timer_table_entry);
-   pentry = (struct sfi_timer_table_entry *) sb->pentry;
-   totallen = sfi_mtimer_num * sizeof(*pentry);
-   memcpy(sfi_mtimer_array, pentry, totallen);
-   }
-
-   pr_debug("SFI MTIMER info (num = %d):\n", sfi_mtimer_num);
-   pentry = sfi_mtimer_array;
-   for (totallen = 0; totallen < sfi_mtimer_num; totallen++, pentry++) {
-   pr_debug("timer[%d]: paddr = 0x%08x, freq = %dHz,"
-   " irq = %d\n", totallen, (u32)pentry->phys_addr,
-   pentry->freq_hz, pentry->irq);
-   if (!pentry->irq)
-   continue;
-   mp_irq.type = MP_INTSRC;
-   mp_irq.irqtype = mp_INT;
-/* triggering mode edge bit 2-3, active high polarity bit 0-1 */
-   mp_irq.irqflag = 5;
-   mp_irq.srcbus = MP_BUS_ISA;
-   mp_irq.srcbusirq = pentry->irq; /* IRQ */
-   mp_irq.dstapic = MP_APIC_ALL;
-   mp_irq.dstirq = pentry->irq;
-   mp_save_irq(_irq);
-   }
-
-   return 0;
-}
-
-struct sfi_timer_table_entry *sfi_get_mtmr(int hint)
-{
-   int i;
-   if (hint < sfi_mtimer_num) {
-   if (!sfi_mtimer_usage[hint]) {
-   pr_debug("hint taken for timer %d irq %d\n",
-   hint, sfi_mtimer_array[hint].irq);
-   sfi_mtimer_usage[hint] = 1;
-   return _mtimer_array[hint];
-   }
-   }
-   /* take the first timer available */
-   for (i = 0; i < sfi_mtimer_num;) {
-   if (!sfi_mtimer_usage[i]) {
-   sfi_mtimer_usage[i] = 1;
-   return 

[PATCH v10 01/12] mrst: Fixed printk/pr_* related issues

[David Cohen]

From: Kuppuswamy Sathyanarayanan 

Fixed printk and pr_* related issues in mrst related files.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Signed-off-by: David Cohen 
---
 arch/x86/platform/mrst/early_printk_mrst.c | 2 +-
 arch/x86/platform/mrst/mrst.c  | 2 +-
 arch/x86/platform/mrst/vrtc.c  | 5 ++---
 3 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/arch/x86/platform/mrst/early_printk_mrst.c 
b/arch/x86/platform/mrst/early_printk_mrst.c
index 028454f..95880f7 100644
--- a/arch/x86/platform/mrst/early_printk_mrst.c
+++ b/arch/x86/platform/mrst/early_printk_mrst.c
@@ -213,7 +213,7 @@ static void early_mrst_spi_putc(char c)
}
 
if (!timeout)
-   pr_warning("MRST earlycon: timed out\n");
+   pr_warn("MRST earlycon: timed out\n");
else
max3110_write_data(c);
 }
diff --git a/arch/x86/platform/mrst/mrst.c b/arch/x86/platform/mrst/mrst.c
index 3ca5957..b9aeb54 100644
--- a/arch/x86/platform/mrst/mrst.c
+++ b/arch/x86/platform/mrst/mrst.c
@@ -328,7 +328,7 @@ static inline int __init setup_x86_mrst_timer(char *arg)
else if (strcmp("lapic_and_apbt", arg) == 0)
mrst_timer_options = MRST_TIMER_LAPIC_APBT;
else {
-   pr_warning("X86 MRST timer option %s not recognised"
+   pr_warn("X86 MRST timer option %s not recognised"
   " use x86_mrst_timer=apbt_only or lapic_and_apbt\n",
   arg);
return -EINVAL;
diff --git a/arch/x86/platform/mrst/vrtc.c b/arch/x86/platform/mrst/vrtc.c
index 5e355b1..ca4f7d9 100644
--- a/arch/x86/platform/mrst/vrtc.c
+++ b/arch/x86/platform/mrst/vrtc.c
@@ -79,7 +79,7 @@ void vrtc_get_time(struct timespec *now)
/* vRTC YEAR reg contains the offset to 1972 */
year += 1972;
 
-   printk(KERN_INFO "vRTC: sec: %d min: %d hour: %d day: %d "
+   pr_info("vRTC: sec: %d min: %d hour: %d day: %d "
"mon: %d year: %d\n", sec, min, hour, mday, mon, year);
 
now->tv_sec = mktime(year, mon, mday, hour, min, sec);
@@ -109,8 +109,7 @@ int vrtc_set_mmss(const struct timespec *now)
vrtc_cmos_write(tm.tm_sec, RTC_SECONDS);
spin_unlock_irqrestore(_lock, flags);
} else {
-   printk(KERN_ERR
-  "%s: Invalid vRTC value: write of %lx to vRTC failed\n",
+   pr_err("%s: Invalid vRTC value: write of %lx to vRTC failed\n",
__FUNCTION__, now->tv_sec);
retval = -EINVAL;
}
-- 
1.8.4.rc3

--
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 v10 10/12] intel-mid: sfi: allow struct devs_id.get_platform_data to be NULL

[David Cohen]

Intel mid sfi code doesn't need struct devs_id.get_platform_data != NULL.
If the callback is not set, just assume there is no platform_data.

Signed-off-by: David Cohen 
Cc: Kuppuswamy Sathyanarayanan 
---
 arch/x86/platform/intel-mid/sfi.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/x86/platform/intel-mid/sfi.c 
b/arch/x86/platform/intel-mid/sfi.c
index 2f8196d..3f1c171 100644
--- a/arch/x86/platform/intel-mid/sfi.c
+++ b/arch/x86/platform/intel-mid/sfi.c
@@ -70,6 +70,9 @@ struct blocking_notifier_head intel_scu_notifier =
BLOCKING_NOTIFIER_INIT(intel_scu_notifier);
 EXPORT_SYMBOL_GPL(intel_scu_notifier);
 
+#define intel_mid_sfi_get_pdata(dev, priv) \
+   ((dev)->get_platform_data ? (dev)->get_platform_data(priv) : NULL)
+
 /* parse all the mtimer info to a static mtimer array */
 int __init sfi_parse_mtmr(struct sfi_table_header *table)
 {
@@ -334,7 +337,7 @@ static void __init sfi_handle_ipc_dev(struct 
sfi_device_table_entry *pentry,
 
pr_debug("IPC bus, name = %16.16s, irq = 0x%2x\n",
pentry->name, pentry->irq);
-   pdata = dev->get_platform_data(pentry);
+   pdata = intel_mid_sfi_get_pdata(dev, pentry);
 
pdev = platform_device_alloc(pentry->name, 0);
if (pdev == NULL) {
@@ -367,7 +370,7 @@ static void __init sfi_handle_spi_dev(struct 
sfi_device_table_entry *pentry,
spi_info.max_speed_hz,
spi_info.chip_select);
 
-   pdata = dev->get_platform_data(_info);
+   pdata = intel_mid_sfi_get_pdata(dev, _info);
 
spi_info.platform_data = pdata;
if (dev->delay)
@@ -391,7 +394,7 @@ static void __init sfi_handle_i2c_dev(struct 
sfi_device_table_entry *pentry,
i2c_info.type,
i2c_info.irq,
i2c_info.addr);
-   pdata = dev->get_platform_data(_info);
+   pdata = intel_mid_sfi_get_pdata(dev, _info);
i2c_info.platform_data = pdata;
 
if (dev->delay)
@@ -450,7 +453,7 @@ static int __init sfi_parse_devs(struct sfi_table_header 
*table)
 
dev = get_device_id(pentry->type, pentry->name);
 
-   if ((dev == NULL) || (dev->get_platform_data == NULL))
+   if (!dev)
continue;
 
if (dev->device_handler) {
-- 
1.8.4.rc3

--
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] kmod: Run usermodehelpers only on cpus allowed for kthreadd

[Frederic Weisbecker]

On Thu, Oct 17, 2013 at 10:50:26AM -0700, Andrew Morton wrote:
> On Thu, 17 Oct 2013 18:07:28 +0200 Frederic Weisbecker  
> wrote:
> 
> > Couldn't we instead make kthread children (those created with 
> > kthread_create()) to inherit
> > kthread initial affinity? Currently kthread's children have cpu_all_mask. 
> > We could change
> > that behaviour. This way the initial kthread affinity could be inherited 
> > all along.
> 
> I'm wondering if it's clean/logical to tie usermodehelper affinity to
> kthreadd affinity at all.  It's certainly convenient, but they're
> distinct concepts.  What is the reason to not have a separate control
> for usermodehelper cpus-allowed?

Makes sense yeah. In fact what I'm mostly concerned about is that we should
set the affinity of __call_usermodehelper threads through inheritance from
a parent rather than making it setting its affinity itself. Because in the 
latter case,
the usermodehelper thread can run anywhere until it sets its affinity. Whether
this little window of global affinity is short or not, this defeats the initial 
purpose
of this patch that is about isolating CPUs and having them undisturbed.

May be we can do that by setting the affinity of the "khelper" workqueue?
--
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] perf, x86: Optimize intel_pmu_pebs_fixup_ip()

[Linus Torvalds]

On Thu, Oct 17, 2013 at 3:01 PM, Peter Zijlstra  wrote:
>
> Oh wait,.. now that Steven fixed being able to take faults from NMI
> context; we could actually try copy_from_user_inatomic(). Being able to
> directly access userspace would make the whole deal a lot easier again.

Careful! There is one magic piece of state that you need to
save-and-restore if you do this, namely %cr2. Taking a page fault
always writes to %cr2, and we must *not* corrupt it in the NMI
handler.

Also, right now, it looks like we call notify_page_fault() in the
atomic page fault case, and that would be deadly from within an NMI.

But if you move the "in_atomic()" check earlier in __do_page_fault(),
you can *try* to do something like this:

  unsigned long
  copy_from_user_nmi(void *to, const void __user *from, unsigned long n)
  {
unsigned long cr2, flags,ret;

if (__range_not_ok(from, n, TASK_SIZE))
return 0;
local_irq_save(flags);
cr2 = read_cr2();
ret = __copy_from_user_inatomic(to, from, n);
/* Reading cr2 is likely much faster than writing it - but go
check this.. */
if (cr2 != read_cr2())
write_cr2(cr2);
local_irq_restore(flags);
return n - ret;
  }

or something close to that. But you absolutely *have* to save/restore
%cr2 (the above tries to avoid writing it if it didn't change,
somebody should check the timings on that to see whether it makes
sense or not).

 Linus
--
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 03/15] clk: tegra: common periph_clk_enb_refcnt and clks

[Andrew Bresticker]

Hi Peter,

>  static void __init tegra30_clock_init(struct device_node *np)
>  {
> struct device_node *node;
> -   int i;
>
> clk_base = of_iomap(np, 0);
> if (!clk_base) {
> @@ -1916,8 +1910,11 @@ static void __init tegra30_clock_init(struct 
> device_node *np)
> BUG();
> }
>
> -   if (tegra_clk_set_periph_banks(5) < 0)
> +   clks = tegra_clk_init(clk_max, 5);
> +   if (!clks) {
> +   WARN_ON(1);

Really minor nit: it seems strange that we WARN here for t30, but not
for t114 or t20.

Thanks,
Andrew
--
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: AMD Bobcat cpufreq

[Borislav Petkov]

On Thu, Oct 17, 2013 at 11:54:28PM +0300, Joonas Saarinen wrote:
> All right. I'm finally back to re-investigate the issue. The
> requested data can be found at:
> 
> http://users.metropolia.fi/~joonasms/bobcat/
> 
> The CPU underclocks as expected but the turbo multiplier is never
> activated.

Right, first of all, when you reply to people on lkml, please make sure
to use "reply-to-all" in your mail client so that the people who you
reply to can get your message directly instead of possibly missing it in
the lkml flood.

Now, I'd guess this 1.3 GHz power state you're talking about is the
boosted state. Here's how you dump that: build and install the cpupower
tool in the kernel repository's tools/power/cpupower/ directory.

Then, do as root:

$ modprobe msr

because you need this module.

Once you've done that successfully, you need to run as root:

$ cd tools/power/cpupower/
$ LD_LIBRARY_PATH=. ./cpupower frequency-info

 [ Btw, the cpupower tool might already be available in your distro... ]

Anyways, once you run it successfully, you'll get a similar dump as
below which will show you all your power states. Pb0 should be 1333 in
your case and if it says "boost state support: ... Active" then all is
fine and your machine is switching into it but in a burstly manner - it
cannot be running in it all the time because it would explode the TDP
limits of the box.

HTH.

analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 4.0 us.
  hardware limits: 1.40 GHz - 4.00 GHz
  available frequency steps: 4.00 GHz, 3.40 GHz, 2.80 GHz, 2.10 GHz, 1.40 GHz
  available cpufreq governors: powersave, userspace, conservative, ondemand, 
performance
  current policy: frequency should be within 1.40 GHz and 4.00 GHz.
  The governor "ondemand" may decide which speed to use
  within this range.
  current CPU frequency is 2.80 GHz (asserted by call to hardware).
  cpufreq stats: 4.00 GHz:4.85%, 3.40 GHz:0.51%, 2.80 GHz:1.01%, 2.10 
GHz:2.01%, 1.40 GHz:91.62%  (1281567)
  boost state support:
Supported: yes
Active: yes
Boost States: 2
Total States: 7
Pstate-Pb0: 4200MHz (boost state)
Pstate-Pb1: 4100MHz (boost state)
Pstate-P0:  4000MHz
Pstate-P1:  3400MHz
Pstate-P2:  2800MHz
Pstate-P3:  2100MHz
Pstate-P4:  1400MHz

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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 02/15] clk: tegra: simplify periph clock data

[Andrew Bresticker]

Hi Peter,

> @@ -2346,6 +2247,9 @@ static void __init tegra114_clock_init(struct 
> device_node *np)
> if (tegra114_osc_clk_init(clk_base) < 0)
> return;
>
> +   if (tegra_clk_set_periph_banks(5) < 0)

Maybe it would be better to have a #define for this (e.g.
TEGRAxxx_CLK_PERIPH_BANKS)?  Same goes for t20 and t30.

>  /* Global data of Tegra CPU CAR ops */
>  static struct tegra_cpu_car_ops dummy_car_ops;
>  struct tegra_cpu_car_ops *tegra_cpu_car_ops = _car_ops;
>
> +int *periph_clk_enb_refcnt;

This changes seems unrelated.  Perhaps it should go in the one that
makes the common periph_clk_enb_refcnt?

Thanks,
Andrew
--
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.11.4: kernel BUG at fs/buffer.c:1268

[Al Viro]

On Thu, Oct 17, 2013 at 05:11:43PM -0400, George Spelvin wrote:
> Al Viro wrote:
> > Note that do_group_exit() is preceded by
> >spin_unlock_irq(>siglock);
> > so no matter what happened in callers, irq is enabled.  I'd suggest sticking
> > such BUG_ON() into __fput() and trying to reproduce that crap...
> 
> Well, it happened again (error appended).  Can you please clarify what you 
> mean
> by "such BUG_ON()"; I'm having a hard time following the RCU code and 
> determining
> all the situations under which __fput() might be called.

__fput() can be called via task_work_run() or via schedule_work().  That's
all.  And it certainly should never be called with interrupts disabled.
So stick BUG_ON(irqs_disabled()) in it (WARN_ON() might be better, but
not by much).

There are two ways these traces could've happened:
* exit_task_work() called by do_exit() with irqs disabled.
Definitely buggy (and would do really nasty things to several functions
called by do_exit() before that one).  If such BUG_ON() triggers in
__fput(), this is what happens and the next step will be sticking
several BUG_ON(irqs_disabled()) in do_exit() - something like
BUG_ON(irqs_disabled());
exit_sem(tsk);
BUG_ON(irqs_disabled());
exit_shm(tsk);
BUG_ON(irqs_disabled());
exit_files(tsk);
BUG_ON(irqs_disabled());
exit_fs(tsk);
BUG_ON(irqs_disabled());
exit_task_namespaces(tsk);
BUG_ON(irqs_disabled());
exit_task_work(tsk);
and checking which of those triggers; that'll tell us who has disabled it
and forgot to enable.
* __fput() is called with irqs enabled, but somewhere on the
way into ext4 (dput -> iput -> evict inode -> free blocks, now that
unlinked file got closed -> ...) we manage to disable irqs and forget
to enable 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: [PATCH] Bluetooth: Add hci_h4p driver

[Marcel Holtmann]

Hi Pali,

>> This driver adding support for Nokia N900 bluetooth hardware
>> 
>> Signed-off-by: Ville Tervo 
>> Signed-off-by: Pali Rohár 
>> ---
>> drivers/bluetooth/Kconfig |   10 +
>> drivers/bluetooth/Makefile|2 +
>> drivers/bluetooth/hci_h4p/Makefile|7 +
>> drivers/bluetooth/hci_h4p/core.c  | 1085
>> +
>> drivers/bluetooth/hci_h4p/fw-bcm.c|  149 +
>> drivers/bluetooth/hci_h4p/fw-csr.c|  152 +
>> drivers/bluetooth/hci_h4p/fw-ti1273.c |  113 
>> drivers/bluetooth/hci_h4p/fw.c|  166 +
>> drivers/bluetooth/hci_h4p/hci_h4p.h   |  238 
>> drivers/bluetooth/hci_h4p/uart.c  |  203 ++
>> include/linux/bluetooth/hci_h4p.h |   41 ++
>> 11 files changed, 2166 insertions(+)
>> create mode 100644 drivers/bluetooth/hci_h4p/Makefile
>> create mode 100644 drivers/bluetooth/hci_h4p/core.c
>> create mode 100644 drivers/bluetooth/hci_h4p/fw-bcm.c
>> create mode 100644 drivers/bluetooth/hci_h4p/fw-csr.c
>> create mode 100644 drivers/bluetooth/hci_h4p/fw-ti1273.c
>> create mode 100644 drivers/bluetooth/hci_h4p/fw.c
>> create mode 100644 drivers/bluetooth/hci_h4p/hci_h4p.h
>> create mode 100644 drivers/bluetooth/hci_h4p/uart.c
>> create mode 100644 include/linux/bluetooth/hci_h4p.h
>> 
> 
> Can somebody look & comment this patch? What is needed to be part 
> of upstream kernel?

you need to rebase against bluetooth-next at least.

Regards

Marcel

--
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 v5 1/4] i2c: busses: i2c-st: Add ST I2C controller

[Jean-Christophe PLAGNIOL-VILLARD]

On 16:53 Thu 17 Oct , Lee Jones wrote:
> On Thu, 17 Oct 2013, Jean-Christophe PLAGNIOL-VILLARD wrote:
> 
> > On 10:33 Thu 17 Oct , srinivas kandagatla wrote:
> > > On 17/10/13 08:27, Maxime COQUELIN wrote:
> > > > ...
> > > >>> >> +
> > > >>> >> +static struct of_device_id st_i2c_match[] = {
> > > >>> >> + { .compatible = "st,comms-ssc-i2c", },
> > > >> > the rules is to put the first soc that use the ip in the compatible
> > > >> > as st,sti7100-scc-i2c
> > > > Ok. There are no plans to upstream the SH4 platforms, it will only 
> > > > remains in stlinux.com.
> > > > Maybe I can set the first ARM platform (STiH415)?
> > > > That would give st,stih415-ssc-i2c.
> > > NAK, for st,stih415-ssc-i2c naming.
> > > 
> > > IMO, this makes sense when the same IP integration done on different SOC
> > > changes slightly/very differently.
> > > 
> > > But in this case the "comms" IP remains unchanged across all the SOCs.
> > > 
> > > I would still prefer "st,comms-ssc-i2c", allowing a single device driver
> > > to match against several SoCs. ST "comms" IP it is integrated across all
> > > the STi series of SoCs, so we don't want to add new entry in compatible
> > > for every new SOC.
> > 
> > you never need this you always the first SoC that's all
> > 
> > see other bindings on at91 as example sorry NACK
> 
> I'm guessing that using the first SoC is an I2C'isum.
> 
> Guys, if you don't want to be too specific, just make it as generic as
> possible whilest still using the SoC as a POR: st,stih41x-ssc-i2c will
> do for now, as it covers all current bases.

except this is wrong the IP is used on much older SoC than the recent ARM ones

and the DT so please respect the rule first SoC used on

Best Regards,
J.
> 
> -- 
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
--
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] [CRYPTO] kconfig: Corrected a typo

[Jiri Kosina]

On Thu, 17 Oct 2013, Siddharth Goel wrote:

> Corrected a typo in option description in Kconfig
> 
> Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=60848
> 
> Signed-off-by: Siddharth Goel 
> ---
>  crypto/Kconfig |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index 69ce573..84698cf 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -1084,7 +1084,7 @@ config CRYPTO_SERPENT
>  
> Keys are allowed to be from 0 to 256 bits in length, in steps
> of 8 bits.  Also includes the 'Tnepres' algorithm, a reversed
> -   variant of Serpent for compatibility with old kerneli.org code.
> +   variant of Serpent for compatibility with old kernel.org code.

Automatic conversion of kerneli -> kernel is not correct, it's not a typo. 
Please google for "kerneli" in LKML archives.

-- 
Jiri Kosina
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] perf, x86: Optimize intel_pmu_pebs_fixup_ip()

[Peter Zijlstra]

On Thu, Oct 17, 2013 at 11:26:23AM -0700, Linus Torvalds wrote:
> On Thu, Oct 17, 2013 at 9:30 AM, Peter Zijlstra  wrote:
> >
> > So avoid having to call copy_from_user_nmi() for every instruction.
> > Since we already limit the max basic block size, we can easily
> > pre-allocate a piece of memory to copy the entire thing into in one
> > go.
> 
> copy_from_user_nmi() itself is all kinds of nasty.

Oh wait,.. now that Steven fixed being able to take faults from NMI
context; we could actually try copy_from_user_inatomic(). Being able to
directly access userspace would make the whole deal a lot easier again.

I'll go try this tomorrow.
--
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 v9 02/14] mrst: Fixed indentation issues

[David Cohen]

From: Kuppuswamy Sathyanarayanan 

Fixed indentation issues reported by checkpatch script in
mrst related files.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Signed-off-by: David Cohen 
---
 arch/x86/platform/mrst/early_printk_mrst.c |  3 ++-
 arch/x86/platform/mrst/mrst.c  | 24 +---
 2 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/arch/x86/platform/mrst/early_printk_mrst.c 
b/arch/x86/platform/mrst/early_printk_mrst.c
index 95880f7..39ecc27 100644
--- a/arch/x86/platform/mrst/early_printk_mrst.c
+++ b/arch/x86/platform/mrst/early_printk_mrst.c
@@ -219,7 +219,8 @@ static void early_mrst_spi_putc(char c)
 }
 
 /* Early SPI only uses polling mode */
-static void early_mrst_spi_write(struct console *con, const char *str, 
unsigned n)
+static void early_mrst_spi_write(struct console *con, const char *str,
+   unsigned n)
 {
int i;
 
diff --git a/arch/x86/platform/mrst/mrst.c b/arch/x86/platform/mrst/mrst.c
index b9aeb54..235a742 100644
--- a/arch/x86/platform/mrst/mrst.c
+++ b/arch/x86/platform/mrst/mrst.c
@@ -131,7 +131,7 @@ struct sfi_timer_table_entry *sfi_get_mtmr(int hint)
int i;
if (hint < sfi_mtimer_num) {
if (!sfi_mtimer_usage[hint]) {
-   pr_debug("hint taken for timer %d irq %d\n",\
+   pr_debug("hint taken for timer %d irq %d\n",
hint, sfi_mtimer_array[hint].irq);
sfi_mtimer_usage[hint] = 1;
return _mtimer_array[hint];
@@ -679,14 +679,14 @@ static void *msic_thermal_platform_data(void *info)
 /* tc35876x DSI-LVDS bridge chip and panel platform data */
 static void *tc35876x_platform_data(void *data)
 {
-   static struct tc35876x_platform_data pdata;
+   static struct tc35876x_platform_data pdata;
 
-   /* gpio pins set to -1 will not be used by the driver */
-   pdata.gpio_bridge_reset = get_gpio_by_name("LCMB_RXEN");
-   pdata.gpio_panel_bl_en = get_gpio_by_name("6S6P_BL_EN");
-   pdata.gpio_panel_vadd = get_gpio_by_name("EN_VREG_LCD_V3P3");
+   /* gpio pins set to -1 will not be used by the driver */
+   pdata.gpio_bridge_reset = get_gpio_by_name("LCMB_RXEN");
+   pdata.gpio_panel_bl_en = get_gpio_by_name("6S6P_BL_EN");
+   pdata.gpio_panel_vadd = get_gpio_by_name("EN_VREG_LCD_V3P3");
 
-   return 
+   return 
 }
 
 static const struct devs_id __initconst device_ids[] = {
@@ -729,7 +729,7 @@ static int i2c_next_dev;
 
 static void __init intel_scu_device_register(struct platform_device *pdev)
 {
-   if(ipc_next_dev == MAX_IPCDEVS)
+   if (ipc_next_dev == MAX_IPCDEVS)
pr_err("too many SCU IPC devices");
else
ipc_devs[ipc_next_dev++] = pdev;
@@ -872,7 +872,8 @@ static void __init sfi_handle_spi_dev(struct spi_board_info 
*spi_info)
 
while (dev->name[0]) {
if (dev->type == SFI_DEV_TYPE_SPI &&
-   !strncmp(dev->name, spi_info->modalias, 
SFI_NAME_LEN)) {
+   !strncmp(dev->name, spi_info->modalias,
+   SFI_NAME_LEN)) {
pdata = dev->get_platform_data(spi_info);
break;
}
@@ -904,7 +905,7 @@ static void __init sfi_handle_i2c_dev(int bus, struct 
i2c_board_info *i2c_info)
intel_scu_i2c_device_register(bus, i2c_info);
else
i2c_register_board_info(bus, i2c_info, 1);
- }
+}
 
 
 static int __init sfi_parse_devs(struct sfi_table_header *table)
@@ -1034,7 +1035,8 @@ static int __init pb_keys_init(void)
num = sizeof(gpio_button) / sizeof(struct gpio_keys_button);
for (i = 0; i < num; i++) {
gb[i].gpio = get_gpio_by_name(gb[i].desc);
-   pr_debug("info[%2d]: name = %s, gpio = %d\n", i, gb[i].desc, 
gb[i].gpio);
+   pr_debug("info[%2d]: name = %s, gpio = %d\n", i, gb[i].desc,
+   gb[i].gpio);
if (gb[i].gpio == -1)
continue;
 
-- 
1.8.4.rc3

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