Re: [PATCH 2/3] fat: fix time updates for create and delete

[OGAWA Hirofumi]

OGAWA Hirofumi  writes:

> Namjae Jeon  writes:
>
>> 2012/11/12, OGAWA Hirofumi :
>>> Namjae Jeon  writes:
>>>
 Correctly update modification and status change time in case of
 file/directory removal and creation.
>>>
>>> This changelog just explain "what", and it doesn't explain "why". Please
>>> explain why we need this change.
>>>
>>> IIRC, timestamp handling in FAT driver is strange historically. Anyway,
>>> FAT doesn't have "inode change time". It is "creation time" in FAT.
>> Hi. OGAWA.
>> I made this patch after comparing timestamp handlings with MSDOS and XFS.
>> Should timestamp handling of FAT be same with MSDOS ?
>> Am I missing ?
>
> What was difference with XFS, FAT, and MSDOS?

BTW, I recall I checked this, and yes, it is strange. But it is historical.
-- 
OGAWA Hirofumi 
--
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] fat: fix time updates for create and delete

[OGAWA Hirofumi]

Namjae Jeon  writes:

> 2012/11/12, OGAWA Hirofumi :
>> Namjae Jeon  writes:
>>
>>> Correctly update modification and status change time in case of
>>> file/directory removal and creation.
>>
>> This changelog just explain "what", and it doesn't explain "why". Please
>> explain why we need this change.
>>
>> IIRC, timestamp handling in FAT driver is strange historically. Anyway,
>> FAT doesn't have "inode change time". It is "creation time" in FAT.
> Hi. OGAWA.
> I made this patch after comparing timestamp handlings with MSDOS and XFS.
> Should timestamp handling of FAT be same with MSDOS ?
> Am I missing ?

What was difference with XFS, FAT, and MSDOS?
-- 
OGAWA Hirofumi 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/8] Fix coding style in sdhci.c

[Joe Perches]

On Mon, 2012-11-12 at 02:12 -0500, Chris Ball wrote:
> Hi,
> 
> On Sun, Nov 11 2012, Tushar Behera wrote:
> > Yes, I can do that. I did split it specifically so that we could drop
> > any patches if required.
> >
> > I will wait for a word from Chris regarding what he prefers.
> 
> I would want to merge one patch, but I'm afraid I don't generally want
> to merge changes like these.  sdhci.c is one of the most modified files
> in drivers/mmc, so a change like this can create merge conflicts that
> require many people to update their work, and that's not worth it.

I think brace style isn't important enough too.

I suggested this awhile ago, but it went nowhere.

https://lkml.org/lkml/2011/8/11/425


--
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 v11 5/7] virtio_balloon: introduce migration primitives to balloon pages

[Rusty Russell]

Rafael Aquini  writes:

> On Thu, Nov 08, 2012 at 09:32:18AM +1030, Rusty Russell wrote:
>> The first one can be delayed, the second one can be delayed if the host
>> didn't ask for VIRTIO_BALLOON_F_MUST_TELL_HOST (qemu doesn't).
>> 
>> We could implement a proper request queue for these, and return -EAGAIN
>> if the queue fills.  Though in practice, it's not important (it might
>> help performance).
>
> I liked the idea. Give me the directions to accomplish it and I'll give it a 
> try
> for sure.

OK, let's get this applied first, but here are some pointers:

Here's the current callback function when the host has processed the
buffers we put in the queue:

 static void balloon_ack(struct virtqueue *vq)
 {
struct virtio_balloon *vb = vq->vdev->priv;

wake_up(>acked);
 }

It's almost a noop: here's how we use it to make our queues synchronous:

 static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq)
 {
struct scatterlist sg;
unsigned int len;

sg_init_one(, vb->pfns, sizeof(vb->pfns[0]) * vb->num_pfns);

/* We should always be able to add one buffer to an empty queue. */
if (virtqueue_add_buf(vq, , 1, 0, vb, GFP_KERNEL) < 0)
BUG();
virtqueue_kick(vq);

/* When host has read buffer, this completes via balloon_ack */
wait_event(vb->acked, virtqueue_get_buf(vq, ));
 }

And we set up the callback when we create the virtqueue:

vq_callback_t *callbacks[] = { balloon_ack, balloon_ack, stats_request 
};
...
err = vb->vdev->config->find_vqs(vb->vdev, nvqs, vqs, callbacks, names);

So off the top of my head it should be as simple as changing tell_host()
to only wait if the virtqueue_add_buf() fails (ie. queue is full).

Hmm, though you will want to synchronize the inflate and deflate queues:
if we tell the host we're giving a page up we want it to have seen that
before we tell it we're using it again...

Cheers,
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: [3.6.6] panic on reboot / khungtaskd blocked? (WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule)

[Michael Wang]

On 11/12/2012 03:16 PM, Paweł Sikora wrote:
> On Monday 12 of November 2012 11:04:12 Michael Wang wrote:
>> On 11/09/2012 09:48 PM, Paweł Sikora wrote:
>>> Hi,
>>>
>>> during playing with new ups i've caught an nice oops on reboot:
>>>
>>> http://imgbin.org/index.php?page=image=10253
>>>
>>> probably the upstream is also affected.
>>
>> Hi, Paweł
>>
>> Are you using a clean 3.6.6 without any modify?
> 
> yes, pure 3.6.6 form git tree with modular config.
> 
>> Looks like some threads has set itself to be UNINTERRUPTIBLE with out
>> any design on switch itself back later(or the time is too long), are you
>> accidentally using some bad designed module?
> 
> hmm, hard to say. mostly all modules are loaded automatically by kernel.

Could you please provide the whole dmesg in text? your picture lost the
print info of the hung task.

And please try the latest kernel, the issue may already solved(if it is
a issue...).

Regards,
Michael Wang

> 
> # lsmod
> Module  Size  Used by
> nfsv4 125022  1 
> fuse   77993  0 
> nfsv3  34273  1 
> nfs   142878  5 nfsv4,nfsv3
> fscache46225  1 nfs
> nfsd  247413  13 
> lockd  76458  3 nfsv3,nfs,nfsd
> nfs_acl12741  2 nfsv3,nfsd
> auth_rpcgss39901  2 nfsv4,nfsd
> sunrpc211604  31 
> nfsv4,nfsv3,nfs,nfsd,lockd,nfs_acl,auth_rpcgss
> ipmi_si48670  0 
> ipmi_devintf   17521  0 
> ipmi_msghandler43715  2 ipmi_si,ipmi_devintf
> sch_sfq21375  2 
> iptable_nat13182  1 
> nf_nat 24649  1 iptable_nat
> nf_conntrack_ipv4  14594  3 iptable_nat,nf_nat
> nf_conntrack   74130  3 iptable_nat,nf_nat,nf_conntrack_ipv4
> nf_defrag_ipv4 12673  1 nf_conntrack_ipv4
> iptable_filter 12810  0 
> xt_TCPMSS  12707  2 
> xt_tcpudp  12603  2 
> iptable_mangle 12695  1 
> ip_tables  26782  3 iptable_nat,iptable_filter,iptable_mangle
> ip6table_filter12815  0 
> ip6_tables 26942  1 ip6table_filter
> x_tables   27637  8 
> iptable_nat,iptable_filter,xt_TCPMSS,xt_tcpudp,iptable_mangle,ip_tables,ip6table_filter,ip6_tables
> ext4  482400  2 
> jbd2   89967  1 ext4
> crc16  12559  1 ext4
> raid0  17188  2 
> dm_mod 77931  0 
> autofs428341  11 
> dummy  12915  0 
> ide_cd_mod 35359  0 
> cdrom  41920  1 ide_cd_mod
> ata_generic12910  0 
> pata_acpi  13038  0 
> pata_atiixp13271  0 
> ide_pci_generic12866  0 
> igb   125677  0 
> pcspkr 12718  0 
> evdev  17797  0 
> joydev 17457  0 
> sp5100_tco 13697  0 
> powernow_k818109  1 
> freq_table 13743  1 powernow_k8
> mperf  12607  1 powernow_k8
> mgag20038130  1 
> amd64_edac_mod 28812  0 
> edac_core  56455  2 amd64_edac_mod
> kvm_amd55563  0 
> ttm75424  1 mgag200
> kvm   406326  1 kvm_amd
> drm_kms_helper 44701  1 mgag200
> drm   250914  3 mgag200,ttm,drm_kms_helper
> k10temp13126  0 
> hwmon  12853  1 k10temp
> i2c_algo_bit   13257  1 mgag200
> sysimgblt  12588  1 mgag200
> sysfillrect12654  1 mgag200
> syscopyarea12445  1 mgag200
> microcode  18669  0 
> hid_generic12493  0 
> atiixp 12917  0 
> i2c_piix4  13266  0 
> dca14601  1 igb
> ptp18413  1 igb
> pps_core   13770  1 ptp
> edac_mce_amd   22771  1 amd64_edac_mod
> ide_core  108021  3 ide_cd_mod,ide_pci_generic,atiixp
> i2c_core   28918  5 
> mgag200,drm_kms_helper,drm,i2c_algo_bit,i2c_piix4
> processor  31231  1 powernow_k8
> button 13692  0 
> ext3  220064  1 
> jbd77423  1 ext3
> mbcache14316  2 ext4,ext3
> sd_mod 44963  16 
> crc_t10dif 12483  1 sd_mod
> raid1  35216  1 
> md_mod112433  5 raid0,raid1
> ahci   25731  12 
> libahci26007  1 ahci
> libata195604  5 ata_generic,pata_acpi,pata_atiixp,ahci,libahci
> scsi_mod  161576  2 sd_mod,libata
> usbhid 46734  0 
> hid94508  2 hid_generic,usbhid
> ohci_hcd   31595  0 
> ehci_hcd   50048  0 
> usbcore   173967  4 usbhid,ohci_hcd,ehci_hcd
> usb_common 12489  1 usbcore
> 
> BR,
> Paweł.
> 

--
To unsubscribe from this 

Re: [PATCH 2/3] iommu/tegra-smmu.c: fix dentry reference leak in smmu_debugfs_stats_show().

[Hiroshi Doyu]

Cyril Roelandt  wrote @ Sun, 11 Nov 2012 21:49:30 +0100:

> Call to d_find_alias() needs a corresponding dput().
> 
> Signed-off-by: Cyril Roelandt 
> ---

Thanks. Looks ok for me. Acked-by Hiroshi Doyu 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/8] Fix coding style in sdhci.c

[Tushar Behera]

On 11/12/2012 12:42 PM, Chris Ball wrote:
> Hi,
> 
> On Sun, Nov 11 2012, Tushar Behera wrote:
>> Yes, I can do that. I did split it specifically so that we could drop
>> any patches if required.
>>
>> I will wait for a word from Chris regarding what he prefers.
> 
> I would want to merge one patch, but I'm afraid I don't generally want
> to merge changes like these.  sdhci.c is one of the most modified files
> in drivers/mmc, so a change like this can create merge conflicts that
> require many people to update their work, and that's not worth it.
> 
> Thanks,
> 
> - Chris.
> 
Thanks for the information.

-- 
Tushar Behera
--
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/4] thermal: Add new thermal trend type to support quick cooling

[R, Durgadoss]

> -Original Message-
> From: Zhang, Rui
> Sent: Monday, November 12, 2012 12:03 PM
> To: R, Durgadoss
> Cc: Amit Kachhap; linux...@lists.linux-foundation.org; linux-samsung-
> s...@vger.kernel.org; linux-kernel@vger.kernel.org; l...@kernel.org; linux-
> a...@vger.kernel.org; jonghwa3@samsung.com
> Subject: RE: [PATCH 1/4] thermal: Add new thermal trend type to support
> quick cooling
> 
> On Sun, 2012-11-11 at 22:55 -0700, R, Durgadoss wrote:
> > Hi Amit/Rui,
> >
> > > -Original Message-
> > > From: Amit Kachhap [mailto:amit.kach...@linaro.org]
> > > Sent: Friday, November 09, 2012 11:52 AM
> > > To: Zhang, Rui
> > > Cc: linux...@lists.linux-foundation.org; linux-samsung-
> > > s...@vger.kernel.org; linux-kernel@vger.kernel.org; R, Durgadoss;
> > > l...@kernel.org; linux-a...@vger.kernel.org;
> jonghwa3@samsung.com
> > > Subject: Re: [PATCH 1/4] thermal: Add new thermal trend type to
> support
> > > quick cooling
> > >
> > > On 9 November 2012 09:21, Zhang Rui  wrote:
> > > > On Thu, 2012-11-08 at 11:56 +0530, Amit Kachhap wrote:
> > > >> On 8 November 2012 11:31, Zhang Rui  wrote:
> > > >> > On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
> > > >> >> This modification adds 2 new thermal trend type
> > > THERMAL_TREND_RAISE_FULL
> > > >> >> and THERMAL_TREND_DROP_FULL. This thermal trend can be used
> to
> > > quickly
> > > >> >> jump to the upper or lower cooling level instead of incremental
> > > increase
> > > >> >> or decrease.
> > > >> >
> > > >> > IMO, what we need is a new more aggressive cooling governor
> which
> > > always
> > > >> > uses upper limit when the temperature is raising and lower limit
> when
> > > >> > the temperature is dropping.
> > > >> Yes I agree that a new aggressive governor is the best approach but
> > > >> then i thought adding a new trend type is a simple solution to achieve
> > > >> this and since most of the governor logic might be same as the
> > > >> step-wise governor. I have no objection in doing it through governor.
> > > >> >
> > > > hmmm,
> > > > I think a more proper way is to set the cooling state to upper limit
> > > > when it overheats and reduce the cooling state step by step when the
> > > > temperature drops.
> > >
> > > No actually I was thinking of having a  simple governor with a feature
> > > like it only sets to upper level and lower level. Also since the
> > > temperature sensor is capable of interrupting for both increase in
> > > threshold(say 100C)  and fall in threshold (say 90C), so polling or
> > > step increments is not needed at all.
> > > Currently stepwise governor governor does that so we might change the
> > > macro name as,
> > > THERMAL_TREND_RAISE_STEP,
> > > THERMAL_TREND_DROP_STEP,
> > > THERMAL_TREND_RAISE_MAX,
> > > THERMAL_TREND_DROP_MAX,
> > >
> > > and file step_wise.c can be named as state_wise.c or trend_wise.c.
> >
> > Yes, in this particular case, we neither need to poll nor do step wise
> > operations. But, most of the other sensors need at least one of them.
> >
> > So, I think we can try it this way:
> > if (sensor supports interrupt) {
> > 'always' use RAISE_MAX and DROP_MAX;
> > } else {
> > Do Step wise operations
> > }
> >
> why should the generic thermal layer be aware of this?
> 
> IMO, it is the platform thermal driver that is responsible for returning
> THERMAL_TREND_RAISE_STEP or THERMAL_TREND_RAISE_MAX.
> 
> and the step_wise governor just takes action based on the return value
> of .get_trend() callback.

Yes, agree with the flow ..

Thanks,
Durga
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH 2/2] drm: tegra: Add HDMI support

[Thierry Reding]

On Sun, Nov 11, 2012 at 03:46:44PM +0100, Daniel Vetter wrote:
> On Sat, Nov 10, 2012 at 10:01:18PM +0100, Thierry Reding wrote:
> > On Fri, Nov 09, 2012 at 05:00:54PM +0100, Christian König wrote:
> > > On 09.11.2012 16:45, Rafał Miłecki wrote:
> > > >2012/11/9 Thierry Reding :
> > > >>+/* all fields little endian */
> > > >>+struct hdmi_audio_infoframe {
> > > >>+   /* PB0 */
> > > >>+   u8 csum;
> > > >>+
> > > >>+   /* PB1 */
> > > >>+   unsigned cc:3; /* channel count */
> > > >>+   unsigned res1:1;
> > > >>+   unsigned ct:4; /* coding type */
> > > >>+
> > > >>+   /* PB2 */
> > > >>+   unsigned ss:2; /* sample size */
> > > >>+   unsigned sf:3; /* sample frequency */
> > > >>+   unsigned res2:3;
> > > >>+
> > > >>+   /* PB3 */
> > > >>+   unsigned cxt:5; /* coding extention type */
> > > >>+   unsigned res3:3;
> > > >>+
> > > >>+   /* PB4 */
> > > >>+   u8 ca; /* channel/speaker allocation */
> > > >>+
> > > >>+   /* PB5 */
> > > >>+   unsigned res5:3;
> > > >>+   unsigned lsv:4; /* level shift value */
> > > >>+   unsigned dm_inh:1; /* downmix inhibit */
> > > >>+
> > > >>+   /* PB6-10 reserved */
> > > >>+   u8 res6;
> > > >>+   u8 res7;
> > > >>+   u8 res8;
> > > >>+   u8 res9;
> > > >>+   u8 res10;
> > > >>+} __packed;
> > > >I was told it won't work on different endian devices. See
> > > >[RFC][PATCH] drm/radeon/hdmi: define struct for AVI infoframe
> > > >http://lists.freedesktop.org/archives/dri-devel/2012-May/022544.html
> > > 
> > > Yeah, that's indeed true. And honestly adding just another
> > > implementation of the HDMI info frames sounds like somebody should
> > > finally sit down and implement it in a common drm_hdmi.c
> > 
> > So I've been looking at what most other implementations do and it seems
> > a lot just fill the AVI infoframe with zeroes while only a few actually
> > try to put useful information in them. Still in order to plan for a
> > generic solution, I thought maybe something like the below set of
> > structures and functions could work:
> > 
> > /*
> >  * Structure that contains the infoframe fields in a form that allows them 
> > to
> >  * be easily accessed from C code.
> >  */
> > struct hdmi_avi_infoframe;
> > 
> > /*
> >  * DRM helper to fill a struct hdmi_avi_infoframe with information taken 
> > from
> >  * a struct drm_display_mode. Fields that cannot automatically be derived by
> >  * looking at a struct drm_display_mode are set to the default values.
> >  */
> > int drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe 
> > *frame,
> >  struct drm_display_mode *mode);
> > 
> > /*
> >  * Packs the struct hdmi_avi_infoframe into a binary buffer that can be
> >  * programmed to the hardware-specific registers.
> >  */
> > ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe *frame,
> > void *buffer, size_t size);
> > 
> > Such a scheme would allow DRM drivers to call the helper and tweak the
> > fields in the structure if the want or need to and call the packing
> > function to obtain a buffer that they can write to the controller.
> > 
> > Does that sound at all reasonable?
> 
> Sounds good, especially the disdinction between the infoframe creation and
> packing. E.g. on intel sdvo outputs we may not put in one of the ECC bytes
> (since the hw creates it), so we need our own packing code there.

Actually what I had in mind was a packed binary representation of
infoframes as specified by HDMI 1.3a (I don't have access to 1.4, but I
would think it doesn't differ in this respect) in section 5.3 and 5.3.5
more specifically. According to the specification, the ECC bytes only
come into play at a later stage, when data is actually transmitted on
the TMDS link (Section 5.2.3). Tegra, nouveau and radeon also seem to be
doing the checksumming in hardware, so I guess we don't need to compute
the ECC bytes in software at all (for now).

Once we have this for the AVI infoframes I guess the same concept can be
used for audio infoframes and for vendor-specific infoframes (for HDMI
1.4 3D).

Thierry


pgpFZv2uW2h7E.pgp
Description: PGP signature

Re: [3.6.6] panic on reboot / khungtaskd blocked? (WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule)

[Paweł Sikora]

On Monday 12 of November 2012 11:04:12 Michael Wang wrote:
> On 11/09/2012 09:48 PM, Paweł Sikora wrote:
> > Hi,
> > 
> > during playing with new ups i've caught an nice oops on reboot:
> > 
> > http://imgbin.org/index.php?page=image=10253
> > 
> > probably the upstream is also affected.
> 
> Hi, Paweł
> 
> Are you using a clean 3.6.6 without any modify?

yes, pure 3.6.6 form git tree with modular config.

> Looks like some threads has set itself to be UNINTERRUPTIBLE with out
> any design on switch itself back later(or the time is too long), are you
> accidentally using some bad designed module?

hmm, hard to say. mostly all modules are loaded automatically by kernel.

# lsmod
Module  Size  Used by
nfsv4 125022  1 
fuse   77993  0 
nfsv3  34273  1 
nfs   142878  5 nfsv4,nfsv3
fscache46225  1 nfs
nfsd  247413  13 
lockd  76458  3 nfsv3,nfs,nfsd
nfs_acl12741  2 nfsv3,nfsd
auth_rpcgss39901  2 nfsv4,nfsd
sunrpc211604  31 nfsv4,nfsv3,nfs,nfsd,lockd,nfs_acl,auth_rpcgss
ipmi_si48670  0 
ipmi_devintf   17521  0 
ipmi_msghandler43715  2 ipmi_si,ipmi_devintf
sch_sfq21375  2 
iptable_nat13182  1 
nf_nat 24649  1 iptable_nat
nf_conntrack_ipv4  14594  3 iptable_nat,nf_nat
nf_conntrack   74130  3 iptable_nat,nf_nat,nf_conntrack_ipv4
nf_defrag_ipv4 12673  1 nf_conntrack_ipv4
iptable_filter 12810  0 
xt_TCPMSS  12707  2 
xt_tcpudp  12603  2 
iptable_mangle 12695  1 
ip_tables  26782  3 iptable_nat,iptable_filter,iptable_mangle
ip6table_filter12815  0 
ip6_tables 26942  1 ip6table_filter
x_tables   27637  8 
iptable_nat,iptable_filter,xt_TCPMSS,xt_tcpudp,iptable_mangle,ip_tables,ip6table_filter,ip6_tables
ext4  482400  2 
jbd2   89967  1 ext4
crc16  12559  1 ext4
raid0  17188  2 
dm_mod 77931  0 
autofs428341  11 
dummy  12915  0 
ide_cd_mod 35359  0 
cdrom  41920  1 ide_cd_mod
ata_generic12910  0 
pata_acpi  13038  0 
pata_atiixp13271  0 
ide_pci_generic12866  0 
igb   125677  0 
pcspkr 12718  0 
evdev  17797  0 
joydev 17457  0 
sp5100_tco 13697  0 
powernow_k818109  1 
freq_table 13743  1 powernow_k8
mperf  12607  1 powernow_k8
mgag20038130  1 
amd64_edac_mod 28812  0 
edac_core  56455  2 amd64_edac_mod
kvm_amd55563  0 
ttm75424  1 mgag200
kvm   406326  1 kvm_amd
drm_kms_helper 44701  1 mgag200
drm   250914  3 mgag200,ttm,drm_kms_helper
k10temp13126  0 
hwmon  12853  1 k10temp
i2c_algo_bit   13257  1 mgag200
sysimgblt  12588  1 mgag200
sysfillrect12654  1 mgag200
syscopyarea12445  1 mgag200
microcode  18669  0 
hid_generic12493  0 
atiixp 12917  0 
i2c_piix4  13266  0 
dca14601  1 igb
ptp18413  1 igb
pps_core   13770  1 ptp
edac_mce_amd   22771  1 amd64_edac_mod
ide_core  108021  3 ide_cd_mod,ide_pci_generic,atiixp
i2c_core   28918  5 
mgag200,drm_kms_helper,drm,i2c_algo_bit,i2c_piix4
processor  31231  1 powernow_k8
button 13692  0 
ext3  220064  1 
jbd77423  1 ext3
mbcache14316  2 ext4,ext3
sd_mod 44963  16 
crc_t10dif 12483  1 sd_mod
raid1  35216  1 
md_mod112433  5 raid0,raid1
ahci   25731  12 
libahci26007  1 ahci
libata195604  5 ata_generic,pata_acpi,pata_atiixp,ahci,libahci
scsi_mod  161576  2 sd_mod,libata
usbhid 46734  0 
hid94508  2 hid_generic,usbhid
ohci_hcd   31595  0 
ehci_hcd   50048  0 
usbcore   173967  4 usbhid,ohci_hcd,ehci_hcd
usb_common 12489  1 usbcore

BR,
Paweł.
--
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 tools: Add gtk. config option for launching GTK browser

[Pekka Enberg]

On Mon, 12 Nov 2012, Namhyung Kim wrote:
> From: Namhyung Kim 
> 
> Add config option for launching GTK browser for the specified command
> by default.  Currently only 'report' command is supported.
> 
> Adding following line to the perfconfig file will have a same effect
> of specifying --gtk option on command line (unless other related
> options are not given).
> 
> $ cat ~/.perfconfig
> [gtk]
> report = true
> 
> Cc: Pekka Enberg 
> Signed-off-by: Namhyung Kim 

Acked-by: Pekka Enberg 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/8] Fix coding style in sdhci.c

[Chris Ball]

Hi,

On Sun, Nov 11 2012, Tushar Behera wrote:
> Yes, I can do that. I did split it specifically so that we could drop
> any patches if required.
>
> I will wait for a word from Chris regarding what he prefers.

I would want to merge one patch, but I'm afraid I don't generally want
to merge changes like these.  sdhci.c is one of the most modified files
in drivers/mmc, so a change like this can create merge conflicts that
require many people to update their work, and that's not worth it.

Thanks,

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
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] Set bit 22 in the PL310 (cache controller) AuxCtlr register

[Shiraz Hashim]

On Fri, Nov 09, 2012 at 09:54:01AM +, Will Deacon wrote:
> On Fri, Nov 09, 2012 at 04:01:52AM +, Shiraz Hashim wrote:
> > From: Catalin Marinas 
> > 
> > Clearing bit 22 in the PL310 Auxiliary Control register (shared
> > attribute override enable) has the side effect of transforming Normal
> > Shared Non-cacheable reads into Cacheable no-allocate reads.
> > 
> > Coherent DMA buffers in Linux always have a Cacheable alias via the
> > kernel linear mapping and the processor can speculatively load cache
> > lines into the PL310 controller. With bit 22 cleared, Non-cacheable
> > reads would unexpectedly hit such cache lines leading to buffer
> > corruption.
> 
> Is this still the case with recent kernels? I thought the dma-mapping/cma
> work avoided the cacheable alias, but perhaps I'm mistaken.

I haven't used CMA but DMA mappings are still normal memory
non-cacheable.

--
regards
Shiraz
--
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/2] pinctrl: pxa3xx: Remove phy_base and phy_size from struct pxa3xx_pinmux_info

[Axel Lin]

They are not used, remove them.

Signed-off-by: Axel Lin 
---
 drivers/pinctrl/pinctrl-pxa3xx.c |2 --
 drivers/pinctrl/pinctrl-pxa3xx.h |2 --
 2 files changed, 4 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-pxa3xx.c b/drivers/pinctrl/pinctrl-pxa3xx.c
index 43e3dd0..51f8a38 100644
--- a/drivers/pinctrl/pinctrl-pxa3xx.c
+++ b/drivers/pinctrl/pinctrl-pxa3xx.c
@@ -187,8 +187,6 @@ int pxa3xx_pinctrl_register(struct platform_device *pdev,
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
return -ENOENT;
-   info->phy_base = res->start;
-   info->phy_size = resource_size(res);
info->virt_base = devm_request_and_ioremap(>dev, res);
if (!info->virt_base)
return -ENOMEM;
diff --git a/drivers/pinctrl/pinctrl-pxa3xx.h b/drivers/pinctrl/pinctrl-pxa3xx.h
index 8135744..92fad08 100644
--- a/drivers/pinctrl/pinctrl-pxa3xx.h
+++ b/drivers/pinctrl/pinctrl-pxa3xx.h
@@ -60,8 +60,6 @@ struct pxa3xx_pinmux_info {
struct device *dev;
struct pinctrl_dev *pctrl;
enum pxa_cpu_type cputype;
-   unsigned int phy_base;
-   unsigned int phy_size;
void __iomem *virt_base;
 
struct pxa3xx_mfp_pin *mfp;
-- 
1.7.9.5



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] pinctrl: pxa3xx: Use devm_request_and_ioremap

[Axel Lin]

Use managed resources API to simplify the code.
Also ensure we do request mem_region before ioremap.

Signed-off-by: Axel Lin 
---
 drivers/pinctrl/pinctrl-pxa3xx.c |   10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-pxa3xx.c b/drivers/pinctrl/pinctrl-pxa3xx.c
index f14cd6b..43e3dd0 100644
--- a/drivers/pinctrl/pinctrl-pxa3xx.c
+++ b/drivers/pinctrl/pinctrl-pxa3xx.c
@@ -173,7 +173,6 @@ int pxa3xx_pinctrl_register(struct platform_device *pdev,
 {
struct pinctrl_desc *desc;
struct resource *res;
-   int ret = 0;
 
if (!info || !info->cputype)
return -EINVAL;
@@ -190,21 +189,17 @@ int pxa3xx_pinctrl_register(struct platform_device *pdev,
return -ENOENT;
info->phy_base = res->start;
info->phy_size = resource_size(res);
-   info->virt_base = ioremap(info->phy_base, info->phy_size);
+   info->virt_base = devm_request_and_ioremap(>dev, res);
if (!info->virt_base)
return -ENOMEM;
info->pctrl = pinctrl_register(desc, >dev, info);
if (!info->pctrl) {
dev_err(>dev, "failed to register PXA pinmux driver\n");
-   ret = -EINVAL;
-   goto err;
+   return -EINVAL;
}
pinctrl_add_gpio_range(info->pctrl, _pinctrl_gpio_range);
platform_set_drvdata(pdev, info);
return 0;
-err:
-   iounmap(info->virt_base);
-   return ret;
 }
 
 int pxa3xx_pinctrl_unregister(struct platform_device *pdev)
@@ -212,7 +207,6 @@ int pxa3xx_pinctrl_unregister(struct platform_device *pdev)
struct pxa3xx_pinmux_info *info = platform_get_drvdata(pdev);
 
pinctrl_unregister(info->pctrl);
-   iounmap(info->virt_base);
platform_set_drvdata(pdev, NULL);
return 0;
 }
-- 
1.7.9.5



--
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] fat: fix time updates for create and delete

[Namjae Jeon]

2012/11/12, OGAWA Hirofumi :
> Namjae Jeon  writes:
>
>> Correctly update modification and status change time in case of
>> file/directory removal and creation.
>
> This changelog just explain "what", and it doesn't explain "why". Please
> explain why we need this change.
>
> IIRC, timestamp handling in FAT driver is strange historically. Anyway,
> FAT doesn't have "inode change time". It is "creation time" in FAT.
Hi. OGAWA.
I made this patch after comparing timestamp handlings with MSDOS and XFS.
Should timestamp handling of FAT be same with MSDOS ?
Am I missing ?

Thanks.
>
>> Signed-off-by: Namjae Jeon 
>> Signed-off-by: Amit Sahrawat 
>> ---
>>  fs/fat/dir.c|2 +-
>>  fs/fat/namei_vfat.c |6 +++---
>>  2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/fs/fat/dir.c b/fs/fat/dir.c
>> index 2a18234..c9fca7d 100644
>> --- a/fs/fat/dir.c
>> +++ b/fs/fat/dir.c
>> @@ -1042,7 +1042,7 @@ int fat_remove_entries(struct inode *dir, struct
>> fat_slot_info *sinfo)
>>  }
>>  }
>>
>> -dir->i_mtime = dir->i_atime = CURRENT_TIME_SEC;
>> +dir->i_mtime = dir->i_ctime = CURRENT_TIME_SEC;
>>  if (IS_DIRSYNC(dir))
>>  (void)fat_sync_inode(dir);
>>  else
>> diff --git a/fs/fat/namei_vfat.c b/fs/fat/namei_vfat.c
>> index ac959d6..23bec0d 100644
>> --- a/fs/fat/namei_vfat.c
>> +++ b/fs/fat/namei_vfat.c
>> @@ -684,7 +684,7 @@ static int vfat_add_entry(struct inode *dir, struct
>> qstr *qname, int is_dir,
>>  goto cleanup;
>>
>>  /* update timestamp */
>> -dir->i_ctime = dir->i_mtime = dir->i_atime = *ts;
>> +dir->i_ctime = dir->i_mtime = *ts;
>>  if (IS_DIRSYNC(dir))
>>  (void)fat_sync_inode(dir);
>>  else
>> @@ -826,7 +826,7 @@ static int vfat_rmdir(struct inode *dir, struct dentry
>> *dentry)
>>  drop_nlink(dir);
>>
>>  clear_nlink(inode);
>> -inode->i_mtime = inode->i_atime = CURRENT_TIME_SEC;
>> +inode->i_ctime = CURRENT_TIME_SEC;
>>  fat_detach(inode);
>>  out:
>>  mutex_unlock(_SB(sb)->s_lock);
>> @@ -851,7 +851,7 @@ static int vfat_unlink(struct inode *dir, struct
>> dentry *dentry)
>>  if (err)
>>  goto out;
>>  clear_nlink(inode);
>> -inode->i_mtime = inode->i_atime = CURRENT_TIME_SEC;
>> +inode->i_ctime = CURRENT_TIME_SEC;
>>  fat_detach(inode);
>>  out:
>>  mutex_unlock(_SB(sb)->s_lock);
>
> --
> OGAWA Hirofumi 
>
--
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] pinctrl: Drop selecting PINCONF for MMP2, PXA168 and PXA910

[Axel Lin]

These drivers do not need to select PINCONF.

Signed-off-by: Axel Lin 
---
 drivers/pinctrl/Kconfig |3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 6d5a50b..1d61d89 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -96,7 +96,6 @@ config PINCTRL_MMP2
bool "MMP2 pin controller driver"
depends on ARCH_MMP
select PINCTRL_PXA3xx
-   select PINCONF
 
 config PINCTRL_MXS
bool
@@ -135,13 +134,11 @@ config PINCTRL_PXA168
bool "PXA168 pin controller driver"
depends on ARCH_MMP
select PINCTRL_PXA3xx
-   select PINCONF
 
 config PINCTRL_PXA910
bool "PXA910 pin controller driver"
depends on ARCH_MMP
select PINCTRL_PXA3xx
-   select PINCONF
 
 config PINCTRL_SINGLE
tristate "One-register-per-pin type device tree based pinctrl driver"
-- 
1.7.9.5



--
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/4] thermal: Add new thermal trend type to support quick cooling

[Zhang Rui]

On Sun, 2012-11-11 at 22:55 -0700, R, Durgadoss wrote:
> Hi Amit/Rui,
> 
> > -Original Message-
> > From: Amit Kachhap [mailto:amit.kach...@linaro.org]
> > Sent: Friday, November 09, 2012 11:52 AM
> > To: Zhang, Rui
> > Cc: linux...@lists.linux-foundation.org; linux-samsung-
> > s...@vger.kernel.org; linux-kernel@vger.kernel.org; R, Durgadoss;
> > l...@kernel.org; linux-a...@vger.kernel.org; jonghwa3@samsung.com
> > Subject: Re: [PATCH 1/4] thermal: Add new thermal trend type to support
> > quick cooling
> > 
> > On 9 November 2012 09:21, Zhang Rui  wrote:
> > > On Thu, 2012-11-08 at 11:56 +0530, Amit Kachhap wrote:
> > >> On 8 November 2012 11:31, Zhang Rui  wrote:
> > >> > On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
> > >> >> This modification adds 2 new thermal trend type
> > THERMAL_TREND_RAISE_FULL
> > >> >> and THERMAL_TREND_DROP_FULL. This thermal trend can be used to
> > quickly
> > >> >> jump to the upper or lower cooling level instead of incremental
> > increase
> > >> >> or decrease.
> > >> >
> > >> > IMO, what we need is a new more aggressive cooling governor which
> > always
> > >> > uses upper limit when the temperature is raising and lower limit when
> > >> > the temperature is dropping.
> > >> Yes I agree that a new aggressive governor is the best approach but
> > >> then i thought adding a new trend type is a simple solution to achieve
> > >> this and since most of the governor logic might be same as the
> > >> step-wise governor. I have no objection in doing it through governor.
> > >> >
> > > hmmm,
> > > I think a more proper way is to set the cooling state to upper limit
> > > when it overheats and reduce the cooling state step by step when the
> > > temperature drops.
> > 
> > No actually I was thinking of having a  simple governor with a feature
> > like it only sets to upper level and lower level. Also since the
> > temperature sensor is capable of interrupting for both increase in
> > threshold(say 100C)  and fall in threshold (say 90C), so polling or
> > step increments is not needed at all.
> > Currently stepwise governor governor does that so we might change the
> > macro name as,
> > THERMAL_TREND_RAISE_STEP,
> > THERMAL_TREND_DROP_STEP,
> > THERMAL_TREND_RAISE_MAX,
> > THERMAL_TREND_DROP_MAX,
> > 
> > and file step_wise.c can be named as state_wise.c or trend_wise.c.
> 
> Yes, in this particular case, we neither need to poll nor do step wise
> operations. But, most of the other sensors need at least one of them.
> 
> So, I think we can try it this way:
>   if (sensor supports interrupt) {
>   'always' use RAISE_MAX and DROP_MAX;
>   } else {
>   Do Step wise operations
>   }
> 
why should the generic thermal layer be aware of this?

IMO, it is the platform thermal driver that is responsible for returning
THERMAL_TREND_RAISE_STEP or THERMAL_TREND_RAISE_MAX.

and the step_wise governor just takes action based on the return value
of .get_trend() callback.

thanks,
rui

--
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] ARM: select PINCTRL for ARCH_MMP

[Axel Lin]

This makes PINCTRL related config options visible.
Otherwise there is no way to build pinctrl drivers for MMP2, PXA168 and PXA910.

Signed-off-by: Axel Lin 
---
 arch/arm/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 48eea16..24e9339 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -581,6 +581,7 @@ config ARCH_MMP
select GPIO_PXA
select IRQ_DOMAIN
select NEED_MACH_GPIO_H
+   select PINCTRL
select PLAT_PXA
select SPARSE_IRQ
help
-- 
1.7.9.5



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

[GIT PULL] a LED fix for 3.7

[Bryan Wu]

Hi Linus,

Please consider the following changes since commit
77b67063bb6bce6d475e910d3b886a606d0d91f7:

  Linux 3.7-rc5 (2012-11-11 13:44:33 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git
fixes-for-3.7

for you to fetch changes up to 0b8728d6f140dc20690384286ade47c956edc999:

  ledtrig-cpu: kill useless mutex to fix sleep in atomic context
(2012-11-11 12:09:43 -0800)


Nathan Lynch (1):
  ledtrig-cpu: kill useless mutex to fix sleep in atomic context

 drivers/leds/ledtrig-cpu.c |   21 -
 1 file changed, 21 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V5 2/2] Thermal: Add ST-Ericsson DB8500 thermal properties and platform data.

[Zhang Rui]

On Fri, 2012-11-09 at 19:29 +0800, hongbo.zhang wrote:
> From: "hongbo.zhang" 
> 
> This patch adds device tree properties for ST-Ericsson DB8500 thermal driver,
> also adds the platform data to support the old fashion.
> 
> Signed-off-by: hongbo.zhang 
> Reviewed-by: Viresh Kumar 

hmmm,

who should take this patch?
I'd like to see ACK from the maintainer of these code before applying
them to thermal tree.

thanks,
rui
> ---
>  arch/arm/boot/dts/dbx5x0.dtsi  | 14 +
>  arch/arm/boot/dts/snowball.dts | 31 ++
>  arch/arm/configs/u8500_defconfig   |  2 ++
>  arch/arm/mach-ux500/board-mop500.c | 64 
> ++
>  4 files changed, 111 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
> index 4b0e0ca..731086b 100644
> --- a/arch/arm/boot/dts/dbx5x0.dtsi
> +++ b/arch/arm/boot/dts/dbx5x0.dtsi
> @@ -203,6 +203,14 @@
>   reg = <0x80157450 0xC>;
>   };
>  
> + thermal@801573c0 {
> + compatible = "stericsson,db8500-thermal";
> + reg = <0x801573c0 0x40>;
> + interrupts = <21 0x4>, <22 0x4>;
> + interrupt-names = "IRQ_HOTMON_LOW", 
> "IRQ_HOTMON_HIGH";
> + status = "disabled";
> +  };
> +
>   db8500-prcmu-regulators {
>   compatible = 
> "stericsson,db8500-prcmu-regulator";
>  
> @@ -660,5 +668,11 @@
>   ranges = <0 0x5000 0x400>;
>   status = "disabled";
>   };
> +
> + cpufreq-cooling {
> + compatible = "stericsson,db8500-cpufreq-cooling";
> + status = "disabled";
> +  };
> +
>   };
>  };
> diff --git a/arch/arm/boot/dts/snowball.dts b/arch/arm/boot/dts/snowball.dts
> index 702c0ba..c6f85f0 100644
> --- a/arch/arm/boot/dts/snowball.dts
> +++ b/arch/arm/boot/dts/snowball.dts
> @@ -99,6 +99,33 @@
>   status = "okay";
>   };
>  
> + prcmu@80157000 {
> + thermal@801573c0 {
> + num-trips = <4>;
> +
> + trip0-temp = <7>;
> + trip0-type = "active";
> + trip0-cdev-num = <1>;
> + trip0-cdev-name0 = "thermal-cpufreq-0";
> +
> + trip1-temp = <75000>;
> + trip1-type = "active";
> + trip1-cdev-num = <1>;
> + trip1-cdev-name0 = "thermal-cpufreq-0";
> +
> + trip2-temp = <8>;
> + trip2-type = "active";
> + trip2-cdev-num = <1>;
> + trip2-cdev-name0 = "thermal-cpufreq-0";
> +
> + trip3-temp = <85000>;
> + trip3-type = "critical";
> + trip3-cdev-num = <0>;
> +
> + status = "okay";
> +  };
> + };
> +
>   external-bus@5000 {
>   status = "okay";
>  
> @@ -183,5 +210,9 @@
>   reg = <0x33>;
>   };
>   };
> +
> + cpufreq-cooling {
> + status = "okay";
> + };
>   };
>  };
> diff --git a/arch/arm/configs/u8500_defconfig 
> b/arch/arm/configs/u8500_defconfig
> index da68454..250625d 100644
> --- a/arch/arm/configs/u8500_defconfig
> +++ b/arch/arm/configs/u8500_defconfig
> @@ -69,6 +69,8 @@ CONFIG_GPIO_TC3589X=y
>  CONFIG_POWER_SUPPLY=y
>  CONFIG_AB8500_BM=y
>  CONFIG_AB8500_BATTERY_THERM_ON_BATCTRL=y
> +CONFIG_THERMAL=y
> +CONFIG_CPU_THERMAL=y
>  CONFIG_MFD_STMPE=y
>  CONFIG_MFD_TC3589X=y
>  CONFIG_AB5500_CORE=y
> diff --git a/arch/arm/mach-ux500/board-mop500.c 
> b/arch/arm/mach-ux500/board-mop500.c
> index 416d436..b03216b 100644
> --- a/arch/arm/mach-ux500/board-mop500.c
> +++ b/arch/arm/mach-ux500/board-mop500.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -229,6 +230,67 @@ static struct ab8500_platform_data ab8500_platdata = {
>  };
>  
>  /*
> + * Thermal Sensor
> + */
> +
> +static struct resource db8500_thsens_resources[] = {
> + {
> + .name = "IRQ_HOTMON_LOW",
> + .start  = IRQ_PRCMU_HOTMON_LOW,
> + .end= IRQ_PRCMU_HOTMON_LOW,
> + .flags  = IORESOURCE_IRQ,
> + },
> + {
> + .name = "IRQ_HOTMON_HIGH",
> + .start  = IRQ_PRCMU_HOTMON_HIGH,
> + .end= IRQ_PRCMU_HOTMON_HIGH,
> + .flags  = IORESOURCE_IRQ,
> + },
> +};
> +
> +static struct 

Re: [PATCH 00/16 v3] f2fs: introduce flash-friendly file system

[Vyacheslav Dubeyko]

On Sun, 2012-11-11 at 20:42 +0900, Jaegeuk Kim wrote:
> 2012-11-11 (일), 00:55 +0300, Vyacheslav Dubeyko:
> > Hi,
> > 
> > On Nov 10, 2012, at 9:33 PM, Martin Steigerwald wrote:
> > 
> > [snip]
> > > 
> > > merkaba:~> mkfs.f2fs /dev/sdb1
> > > Info: sector size = 512
> > > Info: total sectors = 4093951 (in 512bytes)
> > > Info: zone aligned segment0 blkaddr: 256
> > > Info: This device doesn't support TRIM
> > > Info: format successful
> > > merkaba:~> mount /dev/sdb1 /mnt/zeit
> > > mount: you must specify the filesystem type
> > > merkaba:~#32> mount -t f2fs /dev/sdb1 /mnt/zeit
> > > merkaba:~> df -hT /mnt/zeit
> > > DateisystemTyp  Größe Benutzt Verf. Verw% Eingehängt auf
> > > /dev/sdb1  f2fs  2,0G147M  1,8G8% /mnt/zeit
> > > 
> > 
> > Do you really have trouble with f2fs mount without definition of filesystem 
> > type? If so, it is a bug.
> 
> Could you explain this bug in more detail?
> Or, can anyone comment this?
> 
> Actually, I've looking at the *mount* in linux-utils.
> I suspect something does not support f2fs in linux-utils.
> 

Does this issue reproducible or not on last version of f2fs utilities?
There are some probability that it can be an issue of previous version.

As I can understand, if Linux kernel has support of concrete file system
then it should be mounted as with file system type definition as without
it. From my point of understanding, the linux-utils has some
universality and support of all possible file system than kernel can
support. Or I misunderstand something? I think that it can be an issue
on the kernel side. It needs to analyze system log in the case of issue
reproducibility, I think.

With the best regards,
Vyacheslav Dubeyko.

> > 
> > Moreover, I think that it is really inconvenient that mkfs.f2fs doesn't 
> > output its version. I suggest to output version of f2fs utilities.
> 
> Agreed.
> But, I'd like to note that f2fs is not merged yet.
> IMHO, it'd better give an initial version after f2fs is merged.
> Thanks,
> 
> > 
> > With the best regards,
> > Vyacheslav Dubeyko.
> > 
> 


--
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] Input: spear-keyboard: Add clk_{un}prepare() support

[Viresh Kumar]

On 8 November 2012 19:10, Viresh Kumar  wrote:
> From: Vipul Kumar Samar 
>
> clk_{un}prepare is mandatory for platforms using common clock framework. 
> Because
> for SPEAr we don't do anything in clk_{un}prepare() calls, just call them ones
> in probe/remove.
>
> Signed-off-by: Vipul Kumar Samar 
> Signed-off-by: Viresh Kumar 

Missed applying this one ?
--
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: [BUGFIX] PM: Fix active child counting when disabled and forbidden

[Huang Ying]

On Sun, 2012-11-11 at 21:36 -0500, Alan Stern wrote:
> On Mon, 12 Nov 2012, Huang Ying wrote:
> 
> > > The first question: How should the PCI subsystem prevent the parents of 
> > > driverless VGA devices from being runtime suspended while userspace is 
> > > accessing them?
> > 
> > I think Rafael's patch is good for that.
> 
> But his patch isn't needed if we make these other changes.

Yes.

> > > The second question: Should the PM core allow devices that are disabled
> > > for runtime PM to be in the SUSPENDED state when
> > > dev->power.runtime_auto is clear?
> > 
> > I think that should not be allowed.
> 
> Disallowing it is okay with me too.  But it will require several 
> changes to the code, more than what your patch did.

Yes.  I think so too.

> > > Assuming we don't want to allow this, there's a third question: Should
> > > pm_runtime_allow call pm_runtime_set_suspended if the device is
> > > disabled?
> > 
> > Is it absolute necessary to call pm_runtime_set_suspended?  If the
> > device is disabled, the transition to SUSPENDED state will not be
> > triggered even if the device is ACTIVE.
> 
> It's not absolutely necessary to do this, but we ought to because it 
> will allow the device's parent to be suspended.  If we leave the device 
> in the ACTIVE state then the parent can't be suspended, even when the 
> device is disabled.

I think this is the hard part of the issue.  Now "disabled" and
SUSPENDED state is managed by hand.  IMHO, if we changed
pm_runtime_allow() as you said, we need to change the rule too.  Maybe
something as follow:

- remove pm_runtime_set_suspended/pm_runtime_set_active
- in pm_runtime_disable/pm_runtime_allow, put device into SUSPENDED
state if runtime PM is not forbidden.
- in pm_runtime_forbid/pm_runtime_enable, put device into ACTIVE state.

Best Regards,
Huang Ying


--
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/4] thermal: Add new thermal trend type to support quick cooling

[R, Durgadoss]

Hi Amit/Rui,

> -Original Message-
> From: Amit Kachhap [mailto:amit.kach...@linaro.org]
> Sent: Friday, November 09, 2012 11:52 AM
> To: Zhang, Rui
> Cc: linux...@lists.linux-foundation.org; linux-samsung-
> s...@vger.kernel.org; linux-kernel@vger.kernel.org; R, Durgadoss;
> l...@kernel.org; linux-a...@vger.kernel.org; jonghwa3@samsung.com
> Subject: Re: [PATCH 1/4] thermal: Add new thermal trend type to support
> quick cooling
> 
> On 9 November 2012 09:21, Zhang Rui  wrote:
> > On Thu, 2012-11-08 at 11:56 +0530, Amit Kachhap wrote:
> >> On 8 November 2012 11:31, Zhang Rui  wrote:
> >> > On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
> >> >> This modification adds 2 new thermal trend type
> THERMAL_TREND_RAISE_FULL
> >> >> and THERMAL_TREND_DROP_FULL. This thermal trend can be used to
> quickly
> >> >> jump to the upper or lower cooling level instead of incremental
> increase
> >> >> or decrease.
> >> >
> >> > IMO, what we need is a new more aggressive cooling governor which
> always
> >> > uses upper limit when the temperature is raising and lower limit when
> >> > the temperature is dropping.
> >> Yes I agree that a new aggressive governor is the best approach but
> >> then i thought adding a new trend type is a simple solution to achieve
> >> this and since most of the governor logic might be same as the
> >> step-wise governor. I have no objection in doing it through governor.
> >> >
> > hmmm,
> > I think a more proper way is to set the cooling state to upper limit
> > when it overheats and reduce the cooling state step by step when the
> > temperature drops.
> 
> No actually I was thinking of having a  simple governor with a feature
> like it only sets to upper level and lower level. Also since the
> temperature sensor is capable of interrupting for both increase in
> threshold(say 100C)  and fall in threshold (say 90C), so polling or
> step increments is not needed at all.
> Currently stepwise governor governor does that so we might change the
> macro name as,
> THERMAL_TREND_RAISE_STEP,
> THERMAL_TREND_DROP_STEP,
> THERMAL_TREND_RAISE_MAX,
> THERMAL_TREND_DROP_MAX,
> 
> and file step_wise.c can be named as state_wise.c or trend_wise.c.

Yes, in this particular case, we neither need to poll nor do step wise
operations. But, most of the other sensors need at least one of them.

So, I think we can try it this way:
if (sensor supports interrupt) {
'always' use RAISE_MAX and DROP_MAX;
} else {
Do Step wise operations
}

And this could be plugged into step wise. I don't think we need a
complete new governor just to get this case working.

For this to work, we need a way for the governor to know 'whether the
sensor can work on interrupt mode'. May be introducing a new field in
tzd structure can help us here.

I am fine with any name for the governor :-)

Thanks,
Durga
--
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 Nov 12

[Stephen Rothwell]

Hi all,

Changes since 20121109:

The v4l-dvb tree lost its build failure but gained another so I used the
version from next-20121026.

The pinctrl tree gained a conflict against the slave-dma tree.

The akpm tree lost most of its build failures but I have still reverted a
few patches.  It also gained a conflict against the block tree for which
I removed 4 patches.  It also lost a few patches that turned up elsewhere.



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc,
sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 209 trees (counting Linus' and 28 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (77b6706 Linux 3.7-rc5)
Merging fixes/master (12250d8 Merge branch 'i2c-embedded/for-next' of 
git://git.pengutronix.de/git/wsa/linux)
Merging kbuild-current/rc-fixes (bad9955 menuconfig: Replace CIRCLEQ by 
list_head-style lists.)
Merging arm-current/fixes (6404f0b ARM: 7569/1: mm: uninitialized warning 
corrections)
Merging m68k-current/for-linus (8a745ee m68k: Wire up kcmp)
Merging powerpc-merge/merge (8c23f40 Merge 
git://git.kernel.org/pub/scm/virt/kvm/kvm)
Merging sparc/master (b251f0f Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging net/master (b251f0f Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging sound-current/for-linus (8bb4d9c ALSA: Fix card refcount unbalance)
Merging pci-current/for-linus (ff8e59b PCI/portdrv: Don't create hotplug slots 
unless port supports hotplug)
Merging wireless/master (6fe7cc7 ath9k: Test for TID only in BlockAcks while 
checking tx status)
Merging driver-core.current/driver-core-linus (8f0d816 Linux 3.7-rc3)
Merging tty.current/tty-linus (8f0d816 Linux 3.7-rc3)
Merging usb.current/usb-linus (d99e65b USB: fix build with XEN and 
EARLY_PRINTK_DBGP enabled but USB_SUPPORT disabled)
Merging staging.current/staging-linus (8f0d816 Linux 3.7-rc3)
Merging char-misc.current/char-misc-linus (8f0d816 Linux 3.7-rc3)
Merging input-current/for-linus (40a8120 Input: MT - document new 'flags' 
argument of input_mt_init_slots())
Merging md-current/for-linus (ed30be0 MD RAID10: Fix oops when creating RAID10 
arrays via dm-raid.c)
Merging audit-current/for-linus (c158a35 audit: no leading space in 
audit_log_d_path prefix)
Merging crypto-current/master (9efade1 crypto: cryptd - disable softirqs in 
cryptd_queue_worker to prevent data corruption)
Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops)
Merging dwmw2/master (244dc4e Merge 
git://git.infradead.org/users/dwmw2/random-2.6)
Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to 
inline functions)
Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs 
formatting)
Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for 
of_parse_phandle_with_args)
Merging spi-current/spi/merge (d1c185b of/spi: Fix SPI module loading by using 
proper "spi:" modalias prefixes.)
Merging gpio-current/gpio/merge (96b7064 gpio/tca6424: merge I2C transactions, 
remove cast)
Merging rr-fixes/fixes (237242b virtio: Don't access index after unregister.)
Merging asm-generic/master (9b04ebd asm-generic/io.h: remove asm/cacheflush.h 
include)
Merging arm/for-next (ee05d61 Merge remote-tracking 

Re: [PATCH 1/4] thermal: Add new thermal trend type to support quick cooling

[Zhang Rui]

On Fri, 2012-11-09 at 11:51 +0530, Amit Kachhap wrote:
> On 9 November 2012 09:21, Zhang Rui  wrote:
> > On Thu, 2012-11-08 at 11:56 +0530, Amit Kachhap wrote:
> >> On 8 November 2012 11:31, Zhang Rui  wrote:
> >> > On Thu, 2012-11-08 at 09:56 +0530, Amit Daniel Kachhap wrote:
> >> >> This modification adds 2 new thermal trend type THERMAL_TREND_RAISE_FULL
> >> >> and THERMAL_TREND_DROP_FULL. This thermal trend can be used to quickly
> >> >> jump to the upper or lower cooling level instead of incremental increase
> >> >> or decrease.
> >> >
> >> > IMO, what we need is a new more aggressive cooling governor which always
> >> > uses upper limit when the temperature is raising and lower limit when
> >> > the temperature is dropping.
> >> Yes I agree that a new aggressive governor is the best approach but
> >> then i thought adding a new trend type is a simple solution to achieve
> >> this and since most of the governor logic might be same as the
> >> step-wise governor. I have no objection in doing it through governor.
> >> >
> > hmmm,
> > I think a more proper way is to set the cooling state to upper limit
> > when it overheats and reduce the cooling state step by step when the
> > temperature drops.
> 
> No actually I was thinking of having a  simple governor with a feature
> like it only sets to upper level and lower level. Also since the
> temperature sensor is capable of interrupting for both increase in
> threshold(say 100C)  and fall in threshold (say 90C), so polling or
> step increments is not needed at all.
> Currently stepwise governor governor does that so we might change the
> macro name as,
> THERMAL_TREND_RAISE_STEP,
> THERMAL_TREND_DROP_STEP,
> THERMAL_TREND_RAISE_MAX,
> THERMAL_TREND_DROP_MAX,
> 
> and file step_wise.c can be named as state_wise.c or trend_wise.c.
> 
> I am not sure if it is the best way . How do you feel ?
> 
this sounds good to me.
I'd like to see Durga' comments on this as well.

thanks,
rui
> > what do you think?
> >
> > thanks,
> > rui
> >
> >> > I can write such a governor if you do not have time to.
> >> ok. thanks
> >> >
> >> > thanks,
> >> > rui
> >> >>  This is needed for temperature sensors which support rising/falling
> >> >> threshold interrupts and polling can be totally avoided.
> >> >>
> >> >
> >> >
> >> >> Signed-off-by: Amit Daniel Kachhap 
> >> >> Signed-off-by: Amit Daniel Kachhap 
> >> >> ---
> >> >>  drivers/thermal/step_wise.c |   19 +++
> >> >>  include/linux/thermal.h |2 ++
> >> >>  2 files changed, 17 insertions(+), 4 deletions(-)
> >> >>
> >> >> diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
> >> >> index 1242cff..0d2d8d6 100644
> >> >> --- a/drivers/thermal/step_wise.c
> >> >> +++ b/drivers/thermal/step_wise.c
> >> >> @@ -35,6 +35,10 @@
> >> >>   *   state for this trip point
> >> >>   *b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
> >> >>   *   state for this trip point
> >> >> + *c. if the trend is THERMAL_TREND_RAISE_FULL, use highest cooling
> >> >> + *   state for this trip point
> >> >> + *d. if the trend is THERMAL_TREND_DROP_FULL, use lowest cooling
> >> >> + *   state for this trip point
> >> >>   */
> >> >>  static unsigned long get_target_state(struct thermal_instance 
> >> >> *instance,
> >> >>   enum thermal_trend trend)
> >> >> @@ -50,7 +54,10 @@ static unsigned long get_target_state(struct 
> >> >> thermal_instance *instance,
> >> >>   } else if (trend == THERMAL_TREND_DROPPING) {
> >> >>   cur_state = cur_state > instance->lower ?
> >> >>   (cur_state - 1) : instance->lower;
> >> >> - }
> >> >> + } else if (trend == THERMAL_TREND_RAISE_FULL)
> >> >> + cur_state = instance->upper;
> >> >> + else if (trend == THERMAL_TREND_DROP_FULL)
> >> >> + cur_state = instance->lower;
> >> >>
> >> >>   return cur_state;
> >> >>  }
> >> >> @@ -87,7 +94,8 @@ static void update_instance_for_throttle(struct 
> >> >> thermal_zone_device *tz,
> >> >>  }
> >> >>
> >> >>  static void update_instance_for_dethrottle(struct thermal_zone_device 
> >> >> *tz,
> >> >> - int trip, enum thermal_trip_type 
> >> >> trip_type)
> >> >> + int trip, enum thermal_trip_type 
> >> >> trip_type,
> >> >> + enum thermal_trend trend)
> >> >>  {
> >> >>   struct thermal_instance *instance;
> >> >>   struct thermal_cooling_device *cdev;
> >> >> @@ -101,7 +109,10 @@ static void update_instance_for_dethrottle(struct 
> >> >> thermal_zone_device *tz,
> >> >>   cdev = instance->cdev;
> >> >>   cdev->ops->get_cur_state(cdev, _state);
> >> >>
> >> >> - instance->target = cur_state > instance->lower ?
> >> >> + if (trend == THERMAL_TREND_DROP_FULL)
> >> >> + instance->target = instance->lower;
> >> >> + else
> 

[PATCH] perf tools: Fix compile error on NO_NEWT=1 build

[Namhyung Kim]

From: Namhyung Kim 

CC builtin-annotate.o
In file included from util/evsel.h:10:0,
 from util/evlist.h:8,
 from builtin-annotate.c:20:
util/hist.h: In function ‘script_browse’:
util/hist.h:198:45: error: unused parameter ‘script_opt’ 
[-Werror=unused-parameter]
cc1: all warnings being treated as errors
make: *** [builtin-annotate.o] Error 1
make: *** Waiting for unfinished jobs

Cc: Feng Tang 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/hist.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 1278c2c72a96..8b091a51e4a2 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -195,7 +195,7 @@ static inline int hist_entry__tui_annotate(struct 
hist_entry *self
return 0;
 }
 
-static inline int script_browse(const char *script_opt)
+static inline int script_browse(const char *script_opt __maybe_unused)
 {
return 0;
 }
-- 
1.7.11.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: Bisected regression: iterate_fd() selinux change affects flash plugin

[Pavel Roskin]

Quoting Pavel Roskin :


Hello, Al!

I have noticed that Mozilla Firefox gets stuck for seconds or minutes
on some sites, in particular on Facebook with Linux 3.7-rc1 and newer
mainline kernels.  Disabling flash plugin fixes the delays.

This is a Fedora 17 system with SELinux enabled, on x86_64
architecture, with all updates, with LXDE desktop.  It's not the Fedora
16 system I mentioned before, it has never had LXDE login problems due
to replace_fd().

Bisecting lead me to the patch that introduced iterate_fd():

commit c3c073f808b22dfae15ef8412b6f7b998644139a
Author: Al Viro 
Date:   Tue Aug 21 22:32:06 2012 -0400

new helper: iterate_fd()

iterates through the opened files in given descriptor table,
calling a supplied function; we stop once non-zero is returned.
Callback gets struct file *, descriptor number and const void *
argument passed to iterator.  It is called with files->file_lock
held, so it is not allowed to block.

tty_io, netprio_cgroup and selinux flush_unauthorized_files()
converted to its use.

Signed-off-by: Al Viro 

I have found that reverting the changes to security/selinux/hooks.c is
sufficient to restore the correct behavior.

--
Regards,
Pavel Roskin


I've made a bugzilla entry for the bug and put a preliminary patch there.
https://bugzilla.kernel.org/show_bug.cgi?id=50401

--
Regards,
Pavel Roskin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] regulator: core: Update regulator_is_supported_voltage for fixed voltages

[Tushar Behera]

On 11/09/2012 10:39 PM, Mark Brown wrote:
> On Fri, Nov 09, 2012 at 04:21:49PM +0530, Tushar Behera wrote:
> 
>> In case of fixed regulators for which voltage cannot be changed,
>> regulator_is_supported_voltage should return success only if the
>> min_uV and max_uV parameters are same and it is equal to the current
>> voltage of the regulator.
> 
> This makes no sense to me at all.  The caller is asking if it's possible
> to set the voltage between the minimum and maximum values, any voltage
> in that range should be OK.  Your patch makes the function massively
> less useful.
> 

Ok.

In that case, we should modify the test condition as following.
Currently it passes success when the regulator voltage is less than both
min_uV and max_uV. If ok, I will send another patch for this.

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 1a35251..e90e5c3 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1974,7 +1974,7 @@ int regulator_is_supported_voltage(struct
regulator *regulator,
if (!(rdev->constraints->valid_ops_mask &
REGULATOR_CHANGE_VOLTAGE)) {
ret = regulator_get_voltage(regulator);
if (ret >= 0)
-   return (min_uV >= ret && ret <= max_uV);
+   return (ret >= min_uV && ret <= max_uV);
else
return ret;
}


-- 
Tushar Behera
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/8] Fix coding style in sdhci.c

[Tushar Behera]

On 11/12/2012 07:54 AM, Jaehoon Chung wrote:
> Hi Tushar,
> 
> Could you make one patch? Why do you separate patches?
> 

Yes, I can do that. I did split it specifically so that we could drop
any patches if required.

I will wait for a word from Chris regarding what he prefers.


> Best Regards,
> Jaehoon Chung
> 
> On 11/09/2012 08:39 PM, Tushar Behera wrote:
>> Documents/CodingStyle Chapter 3 recommends usage of braces for both
>> if and else statements if any of the branches contains multiple
>> statements.
>>
>> Cleaning up drivers/mmc/host/sdhci.c for all these occurrences.
>>
>> Tushar Behera (8):
>>   mmc: sdhci: fix coding style in sdhci_calc_timeout
>>   mmc: sdhci: fix coding style in sdhci_set_transfer_mode
>>   mmc: sdhci: fix coding style in sdhci_finish_data
>>   mmc: sdhci: fix coding style in sdhci_set_clock
>>   mmc: sdhci: fix coding style in sdhci_do_set_ios
>>   mmc: sdhci: fix coding style in sdhci_execute_tuning
>>   mmc: sdhci: fix coding style in sdhci_data_irq
>>   mmc: sdhci: fix coding style in sdhci_add_host
>>
>>  drivers/mmc/host/sdhci.c |   58 
>> +
>>  1 files changed, 32 insertions(+), 26 deletions(-)
>>
> 


-- 
Tushar Behera
--
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: manual merge of the akpm tree with the block tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
drivers/memstick/core/ms_block.h between commit 0604fa04ccc7 ("memstick:
add support for legacy memorysticks") that use to be in the block tree
and commits "memstick: remove unused field from state struct", "memstick:
ms_block: fix compile issue", "memstick: use after free in
msb_disk_release()" and "memstick: memory leak on error in msb_ftl_scan
()" from the akpm tree.

The block tree commit has been dropped, so the 4 akpm tree patches no
longer have anything to apply to, so I have dropped them.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgppGcDnhKEZy.pgp
Description: PGP signature

Re: [PATCH update 0/3] HW-latency: hardware latency test 0.10

[Jon Masters]

On 11/10/2012 09:48 PM, Luming Yu wrote:

> Update the previous patch series to ACK all comments I've recevied so far
> for the tool: e.g. 1.Acked Jon Masters in source code as many code are from
> jcm, thanks very much Jon. 2. squashed all changes against new file I added 
> into
> one. 3. Make it useful on non-x86.

Thanks for taking this and doing the heavy lifting to get it upstream! I
wrote the original SMI detector really for RT debug purposes as we had
OEM systems that would generate large latencies and it was easier to
prove the point with nice graphs showing where the BIOS was injecting
unwanted SMIs. Glad to see the work being done to make it more generic
in nature. Maybe I'll come back with some ARM patches ;)

Actually this exercise was very informative because it has helped shape
my input on ARMv8 designs. I'm very keen to get away from a world in
which world+dog feature is implemented inside an SMI-like context. It
should be done via a dedicated management processor (on-chip) instead.

Jon.

--
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: linux-next: build warning after merge of the final tree (akpm tree related)

[Stephen Rothwell]

Hi Michel,

On Thu, 8 Nov 2012 20:30:47 -0800 Michel Lespinasse  wrote:
>
> commit 1c98949798ce7a1d4a910775623e1830cf88a92c
> Author: Michel Lespinasse 
> Date:   Thu Nov 8 20:26:34 2012 -0800
> 
> fix mm: use vm_unmapped_area() on sparc32 architecture
> 
> diff --git a/arch/sparc/kernel/sys_sparc_32.c 
> b/arch/sparc/kernel/sys_sparc_32.c
> index a59bc637f9af..a20b5ab4c701 100644
> --- a/arch/sparc/kernel/sys_sparc_32.c
> +++ b/arch/sparc/kernel/sys_sparc_32.c
> @@ -38,7 +38,6 @@ asmlinkage unsigned long sys_getpagesize(void)
>  
>  unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr, 
> unsigned long len, unsigned long pgoff, unsigned long flags)
>  {
> - struct vm_area_struct * vmm;
>   struct vm_unmapped_area_info info;
>  
>   if (flags & MAP_FIXED) {
> 
> commit aa96ebbc9ec664ddafc841f7631c4a092b10c0d8
> Author: Michel Lespinasse 
> Date:   Thu Nov 8 20:25:48 2012 -0800
> 
> fix mm: use vm_unmapped_area() in hugetlbfs on sparc64 architecture
> 
> diff --git a/arch/sparc/mm/hugetlbpage.c b/arch/sparc/mm/hugetlbpage.c
> index 42e5dba6cb26..d2b59441ebdd 100644
> --- a/arch/sparc/mm/hugetlbpage.c
> +++ b/arch/sparc/mm/hugetlbpage.c
> @@ -60,7 +60,6 @@ hugetlb_get_unmapped_area_topdown(struct file *filp, const 
> unsigned long addr0,
> const unsigned long pgoff,
> const unsigned long flags)
>  {
> - struct vm_area_struct *vma;
>   struct mm_struct *mm = current->mm;
>   unsigned long addr = addr0;
>   struct vm_unmapped_area_info info;
> 
> commit ff4dd9742ce0a5f7c703013e70eeb84b845c8fa2
> Author: Michel Lespinasse 
> Date:   Thu Nov 8 20:24:53 2012 -0800
> 
> mm-use-vm_unmapped_area-on-sparc64-architecture-fix2
> 
> diff --git a/arch/sparc/kernel/sys_sparc_64.c 
> b/arch/sparc/kernel/sys_sparc_64.c
> index 2a5d61587ca2..a836ee967ecb 100644
> --- a/arch/sparc/kernel/sys_sparc_64.c
> +++ b/arch/sparc/kernel/sys_sparc_64.c
> @@ -89,7 +89,6 @@ unsigned long arch_get_unmapped_area(struct file *filp, 
> unsigned long addr, unsi
>   struct mm_struct *mm = current->mm;
>   struct vm_area_struct * vma;
>   unsigned long task_size = TASK_SIZE;
> - unsigned long start_addr;
>   int do_color_align;
>   struct vm_unmapped_area_info info;
>  
> @@ -191,7 +190,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const 
> unsigned long addr0,
>   info.length = len;
>   info.low_limit = PAGE_SIZE;
>   info.high_limit = mm->mmap_base;
> - info.align_mask = do_colour_align ? (PAGE_MASK & shm_align_mask) : 0;
> + info.align_mask = do_color_align ? (PAGE_MASK & (SHMLBA - 1)) : 0;
>   info.align_offset = pgoff << PAGE_SHIFT;
>   addr = vm_unmapped_area();
>  
> 
> commit ed558f3723a4ac2fb71d6c8fc70116994af6e61d
> Author: Michel Lespinasse 
> Date:   Thu Nov 8 20:22:36 2012 -0800
> 
> mm-use-vm_unmapped_area-on-arm-architecture-fix2
> 
> diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
> index f4fec6d43d50..10062ceadd1c 100644
> --- a/arch/arm/mm/mmap.c
> +++ b/arch/arm/mm/mmap.c
> @@ -57,7 +57,6 @@ arch_get_unmapped_area(struct file *filp, unsigned long 
> addr,
>  {
>   struct mm_struct *mm = current->mm;
>   struct vm_area_struct *vma;
> - unsigned long start_addr;
>   int do_align = 0;
>   int aliasing = cache_is_vipt_aliasing();
>   struct vm_unmapped_area_info info;
> 

All added to the akpm tree today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp8V7RYxyL76.pgp
Description: PGP signature

Re: linux-next: build failure after merge of the final tree (akpm tree related)

[Stephen Rothwell]

Hi Andrew,

On Thu, 8 Nov 2012 20:01:54 -0800 Andrew Morton  
wrote:
>
> oop, I fixed that but forgot to commit the changes, sorry.
> 
>   s/mm/current->mm/

I have applied this to the akpm tree today:

From: Stephen Rothwell 
Date: Mon, 12 Nov 2012 10:51:18 +1100
Subject: [PATCH] mm: fix for use vm_unmapped_area() in hugetlbfs on i386 
architecture

Fix-from: Adnrew Morton 
Signed-off-by: Stephen Rothwell 
---
 arch/x86/mm/hugetlbpage.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c
index c00c4a4..ae1aa71 100644
--- a/arch/x86/mm/hugetlbpage.c
+++ b/arch/x86/mm/hugetlbpage.c
@@ -296,7 +296,7 @@ static unsigned long 
hugetlb_get_unmapped_area_topdown(struct file *file,
info.flags = VM_UNMAPPED_AREA_TOPDOWN;
info.length = len;
info.low_limit = PAGE_SIZE;
-   info.high_limit = mm->mmap_base;
+   info.high_limit = current->mm->mmap_base;
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
addr = vm_unmapped_area();
-- 
1.7.10.280.gaa39

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp6hY4AL9zd1.pgp
Description: PGP signature

Re: [next:akpm 136/313] mm/mmap.c:1878:6: error: 'mm' undeclared

[Stephen Rothwell]

On Thu, 8 Nov 2012 22:21:50 -0800 Michel Lespinasse  wrote:
>
> commit 34550b95185c1ecfa8882664744c14edda385868
> Author: Michel Lespinasse 
> Date:   Thu Nov 8 22:14:34 2012 -0800
> 
> fix mm: augment vma rbtree with rb_subtree_gap
> 
> diff --git a/mm/mmap.c b/mm/mmap.c
> index d12c69eaf23f..0b8f9d83e2e2 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2032,7 +2032,7 @@ int expand_upwards(struct vm_area_struct *vma, unsigned 
> long address)
>   if (vma->vm_next)
>   vma_gap_update(vma->vm_next);
>   else
> - mm->highest_vm_end = address;
> + vma->vm_mm->highest_vm_end = address;
>   perf_event_mmap(vma);
>   }
>   }

Added to the akpm tree today.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpOCGZGMiqzU.pgp
Description: PGP signature

Re: [next:akpm 157/313] arch/tile/mm/hugetlbpage.c:256:20: error: 'mm' undeclared

[Stephen Rothwell]

On Thu, 8 Nov 2012 22:22:49 -0800 Michel Lespinasse  wrote:
>
> commit 86234092170b43771c3f6257cb320ff6e2c10c52
> Author: Michel Lespinasse 
> Date:   Thu Nov 8 22:13:58 2012 -0800
> 
> fix mm: use vm_unmapped_area() in hugetlbfs on tile architecture
> 
> diff --git a/arch/tile/mm/hugetlbpage.c b/arch/tile/mm/hugetlbpage.c
> index 6f74cce053e1..650ccff8378c 100644
> --- a/arch/tile/mm/hugetlbpage.c
> +++ b/arch/tile/mm/hugetlbpage.c
> @@ -253,7 +253,7 @@ static unsigned long 
> hugetlb_get_unmapped_area_topdown(struct file *file,
>   info.flags = VM_UNMAPPED_AREA_TOPDOWN;
>   info.length = len;
>   info.low_limit = PAGE_SIZE;
> - info.high_limit = mm->mmap_base;
> + info.high_limit = current->mm->mmap_base;
>   info.align_mask = PAGE_MASK & ~huge_page_mask(h);
>   info.align_offset = 0;
>   addr = vm_unmapped_area();

Added to the akpm tree today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpRVbGFXQKWt.pgp
Description: PGP signature

Re: [RFC PATCH 0/3] acpi: Introduce prepare_remove device operation

[Wen Congyang]

At 11/09/2012 02:29 AM, Vasilis Liaskovitis Wrote:
> As discussed in
> https://patchwork.kernel.org/patch/1581581/
> the driver core remove function needs to always succeed. This means we need
> to know that the device can be successfully removed before acpi_bus_trim / 
> acpi_bus_hot_remove_device are called. This can cause panics when 
> OSPM-initiated
> eject (echo 1 > /sys/bus/acpi/devices/PNP/eject) of memory devices fails, 
> since
> the ACPI core goes ahead and ejects the device regardless of whether the 
> memory
> is still in use or not.
> 
> For this reason a new acpi_device operation called prepare_remove is 
> introduced.
> This operation should be registered for acpi devices whose removal (from 
> kernel
> perspective) can fail.  Memory devices fall in this category.
> 
> acpi_bus_hot_remove_device is changed to handle removal in 2 steps:
> - preparation for removal i.e. perform part of removal that can fail outside 
> of
>   ACPI core. Should succeed for device and all its children.
> - if above step was successfull, proceed to actual ACPI removal

If we unbind the device from the driver, we still need to do preparation. But
you don't do it in your patch.

Thanks
Wen Congyang
> 
> acpi_bus_trim is changed accordingly to handle preparation for removal and
> actual removal.
> 
> With this patchset, only acpi memory devices use the new prepare_remove
> device operation. The actual memory removal (VM-related offline and other 
> memory
> cleanups) is moved to prepare_remove. The old remove operation just cleans up
> the acpi structures. Directly ejecting PNP0C80 memory devices works safely. I
> haven't tested yet with an ACPI container which contains memory devices.
> 
> Other ACPI devices (e.g. CPU) do not register prepare_remove callbacks, and
> their OSPM-side eject should not be affected.
> 
> I am not happy with the name prepare_remove. Comments welcome. Let me know if 
> I
> should work more in this direction (I think Yasuaki might also look into this
> and might have a simpler idea)
> 
> Patches are on top of Rafael's linux-pm/linux-next
> 
> Vasilis Liaskovitis (3):
>   acpi: Introduce prepare_remove operation in acpi_device_ops
>   acpi: Make acpi_bus_trim handle device removal preparation
>   acpi_memhotplug: Add prepare_remove operation
> 
>  drivers/acpi/acpi_memhotplug.c |   24 +---
>  drivers/acpi/dock.c|2 +-
>  drivers/acpi/scan.c|   32 +---
>  drivers/pci/hotplug/acpiphp_glue.c |4 ++--
>  drivers/pci/hotplug/sgi_hotplug.c  |2 +-
>  include/acpi/acpi_bus.h|4 +++-
>  6 files changed, 57 insertions(+), 11 deletions(-)
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the pinctrl tree with the slave-dma tree

[Viresh Kumar]

On 12 November 2012 08:45, Stephen Rothwell  wrote:
> Hi Linus,
>
> Today's linux-next merge of the pinctrl tree got a conflict in
> arch/arm/boot/dts/spear1340.dtsi between commit b47394911c26 ("ARM:
> SPEAr13xx: Pass DW DMAC platform data from DT") from the slave-dma tree and 
> commit
> 4ddb1c295752 ("ARM: SPEAr: Add plgpio node in device tree dtsi files")
> from the pinctrl tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Thanks Stephen. It looks perfectly fine. Thanks for keeping ascending order
of node names. :)

> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc arch/arm/boot/dts/spear1340.dtsi
> index 8ea3f66,6c09eb0..000
> --- a/arch/arm/boot/dts/spear1340.dtsi
> +++ b/arch/arm/boot/dts/spear1340.dtsi
> @@@ -24,25 -24,12 +24,31 @@@
> status = "disabled";
> };
>
>  +  dma@ea80 {
>  +  slave_info {
>  +  uart1_tx {
>  +  bus_id = "uart1_tx";
>  +  cfg_hi = <0x6000>;  /* 0xC << 11 
> */
>  +  cfg_lo = <0>;
>  +  src_master = <0>;
>  +  dst_master = <1>;
>  +  };
>  +  uart1_tx {
>  +  bus_id = "uart1_tx";
>  +  cfg_hi = <0x680>;   /* 0xD << 7 */
>  +  cfg_lo = <0>;
>  +  src_master = <1>;
>  +  dst_master = <0>;
>  +  };
>  +  };
>  +  };
>  +
> +   pinmux: pinmux@e070 {
> +   compatible = "st,spear1340-pinmux";
> +   reg = <0xe070 0x1000>;
> +   #gpio-range-cells = <2>;
> +   };
> +
> spi1: spi@5d40 {
> compatible = "arm,pl022", "arm,primecell";
> reg = <0x5d40 0x1000>;
--
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 Resend V2] dt: add helper function to read u8 & u16 variables & arrays

[Viresh Kumar]

On 12 November 2012 01:12, Rob Herring  wrote:
> On 11/11/2012 11:27 AM, Viresh Kumar wrote:
>> On 11 November 2012 19:42, Rob Herring  wrote:
>>> On 11/06/2012 10:22 PM, viresh kumar wrote:
>>
 cluster0: cluster@0 {
 +   data1 = <0x50 0x60 0x70>;
 +   data2 = <0x5000 0x6000 0x7000>;
 +   data3 = <0x5000 0x6000 0x7000>;
>>>
>>> So there is a mismatch in our assumptions. You are just truncating
>>> 32-bit values. I assumed you were using the 8 and 16 bit sizes that are
>>> now supported in dts. I don't think we should just truncate values
>>> blindly. We have support for specifying 8 and 16 values now so you
>>> should use that and define that as part of a binding.
>>
>> Sorry couldn't get your point at all :(
>> What did you mean by "truncating 32 bit values" and how should we
>> tell via DT, that the value passed is 8 bit, 16 bit or 32 bit?
>>
>
> You are trying to retrieve an array of 8 or 16-bit values which are
> stored as 32-bit values in dtb. Why not define them in the binding as 8
> or 16 bit to begin with. Then there is never any ambiguity about their size.
>
> I don't think the size is stored in the dtb. It is only in the dts. You
> need to define the size in the binding definitions and use '/bits/'
> annotation. With this the data is packed. Then the array function used
> should match what the binding defines.

Aha, and in that case incrementing address by 4 in my patch will fail. Right?
Will fix it. Thanks for increasing my knowledge on this :)

--
viresh
--
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: manual merge of the pinctrl tree with the slave-dma tree

[Stephen Rothwell]

Hi Linus,

Today's linux-next merge of the pinctrl tree got a conflict in
arch/arm/boot/dts/spear1340.dtsi between commit b47394911c26 ("ARM:
SPEAr13xx: Pass DW DMAC platform data from DT") from the slave-dma tree and 
commit
4ddb1c295752 ("ARM: SPEAr: Add plgpio node in device tree dtsi files")
from the pinctrl tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/arm/boot/dts/spear1340.dtsi
index 8ea3f66,6c09eb0..000
--- a/arch/arm/boot/dts/spear1340.dtsi
+++ b/arch/arm/boot/dts/spear1340.dtsi
@@@ -24,25 -24,12 +24,31 @@@
status = "disabled";
};
  
 +  dma@ea80 {
 +  slave_info {
 +  uart1_tx {
 +  bus_id = "uart1_tx";
 +  cfg_hi = <0x6000>;  /* 0xC << 11 */
 +  cfg_lo = <0>;
 +  src_master = <0>;
 +  dst_master = <1>;
 +  };
 +  uart1_tx {
 +  bus_id = "uart1_tx";
 +  cfg_hi = <0x680>;   /* 0xD << 7 */
 +  cfg_lo = <0>;
 +  src_master = <1>;
 +  dst_master = <0>;
 +  };
 +  };
 +  };
 +
+   pinmux: pinmux@e070 {
+   compatible = "st,spear1340-pinmux";
+   reg = <0xe070 0x1000>;
+   #gpio-range-cells = <2>;
+   };
+ 
spi1: spi@5d40 {
compatible = "arm,pl022", "arm,primecell";
reg = <0x5d40 0x1000>;


pgpeAzqu3S8kK.pgp
Description: PGP signature

Re: [PATCH v2 3/3] ipgre: capture inner headers during encapsulation

[Joseph Gasparakis]

On Sun, 11 Nov 2012, David Miller wrote:

> 
> Please post the entire series again when making updates to any of
> the patches, thank you.
> 
Will do. Thanks Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 2/3] sched: power aware load balance,

[Alex Shi]

On 11/12/2012 02:49 AM, Preeti Murthy wrote:
> Hi Alex
> I apologise for the delay in replying .

That's all right. I often also busy on other Intel tasks and have no
time to look at LKML. :)
> 
> On Wed, Nov 7, 2012 at 6:57 PM, Alex Shi  wrote:
>> On 11/07/2012 12:37 PM, Preeti Murthy wrote:
>>> Hi Alex,
>>>
>>> What I am concerned about in this patchset as Peter also
>>> mentioned in the previous discussion of your approach
>>> (https://lkml.org/lkml/2012/8/13/139)
>>> is that:
>>>
>>> 1.Using nr_running of two different sched groups to decide which one
>>> can be group_leader or group_min might not be be the right approach,
>>> as this might mislead us to think that a group running one task is less
>>> loaded than the group running three tasks although the former task is
>>> a cpu hogger.
>>>
>>> 2.Comparing the number of cpus with the number of tasks running in a sched
>>> group to decide if the group is underloaded or overloaded again faces
>>> the same issue.The tasks might be short running,not utilizing cpu much.
>>
>> Yes, maybe nr task is not the best indicator. But as first step, it can
>> approve the proposal is a correct path and worth to try more.
>> Considering the old powersaving implement is also judge on nr tasks, and
>> my testing result of this. It may be still a option.
> Hmm.. will think about this and get back.
>>>
>>> I also feel before we introduce another side to the scheduler called
>>> 'power aware',why not try and see if the current scheduler itself can
>>> perform better? We have an opportunity in terms of PJT's patches which
>>> can help scheduler make more realistic decisions in load balance.Also
>>> since PJT's metric is a statistical one,I believe we could vary it to
>>> allow scheduler to do more rigorous or less rigorous power savings.
>>
>> will study the PJT's approach.
>> Actually, current patch set is also a kind of load balance modification,
>> right? :)
> It is true that this is a different approach,in fact we will require
> this approach
> to do power savings because PJT's patches introduce a new 'metric' and not a 
> new
> 'approach' in my opinion, to do smarter load balancing,not power aware
> load balancing per say.So your patch is surely a step towards power
> aware lb.I am just worried about the metric used in it.
>>>
>>> It is true however that this approach will not try and evacuate nearly idle
>>> cpus over to nearly full cpus.That is definitely one of the benefits of your
>>> patch,in terms of power savings,but I believe your patch is not making use
>>> of the right metric to decide that.
>>
>> If one sched group just has one task, and another group just has one
>> LCPU idle, my patch definitely will pull the task to the nearly full
>> sched group. So I didn't understand what you mean 'will not try and
>> evacuate nearly idle cpus over to nearly full cpus'
> No, by 'this approach' I meant the current load balancer integrated with
> the PJT's metric.Your approach does 'evacuate' the nearly idle cpus
> over to the nearly full cpus..

Oh, a misunderstand on 'this approach'. :) Anyway, we are all clear
about this now.

--
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 3/3] ipgre: capture inner headers during encapsulation

[David Miller]

Please post the entire series again when making updates to any of
the patches, thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [3.6.6] panic on reboot / khungtaskd blocked? (WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule)

[Michael Wang]

On 11/09/2012 09:48 PM, Paweł Sikora wrote:
> Hi,
> 
> during playing with new ups i've caught an nice oops on reboot:
> 
> http://imgbin.org/index.php?page=image=10253
> 
> probably the upstream is also affected.

Hi, Paweł

Are you using a clean 3.6.6 without any modify?

Looks like some threads has set itself to be UNINTERRUPTIBLE with out
any design on switch itself back later(or the time is too long), are you
accidentally using some bad designed module?

BTW, it's better to paste whole log in mail with text style not a picture.

Regards,
Michael Wang

> 
> BR,
> Paweł.
> 
> --
> 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/
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/3] ipgre: capture inner headers during encapsulation

[Joseph Gasparakis]

Populating the inner header pointers of skb for ipgre
This patch has been compile-tested only.

v2 Makes sure that checksumming does not take place if the offload flag is set 
in the skb's netdev features

Signed-off-by: Joseph Gasparakis 
Signed-off-by: Peter P Waskiewicz Jr 
---
 net/ipv4/ip_gre.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 7240f8e..e35ed52 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -766,8 +766,10 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, 
struct net_device *dev
intgre_hlen;
__be32 dst;
intmtu;
+   unsigned int offset;
 
-   if (skb->ip_summed == CHECKSUM_PARTIAL &&
+   if (!(skb->dev->features & NETIF_F_HW_CSUM_ENC_BIT) &&
+   skb->ip_summed == CHECKSUM_PARTIAL &&
skb_checksum_help(skb))
goto tx_error;
 
@@ -902,6 +904,17 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, 
struct net_device *dev
tunnel->err_count = 0;
}
 
+   offset = skb->data - skb->head;
+
+   skb_reset_inner_mac_header(skb);
+
+   if (skb->network_header)
+   skb_set_inner_network_header(skb, skb->network_header - offset);
+
+   if (skb->transport_header)
+   skb_set_inner_transport_header(skb, skb->transport_header -
+  offset);
+
max_headroom = LL_RESERVED_SPACE(tdev) + gre_hlen + rt->dst.header_len;
 
if (skb_headroom(skb) < max_headroom || skb_shared(skb)||
-- 
1.7.11.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] perf tools: Add gtk. config option for launching GTK browser

[Namhyung Kim]

From: Namhyung Kim 

Add config option for launching GTK browser for the specified command
by default.  Currently only 'report' command is supported.

Adding following line to the perfconfig file will have a same effect
of specifying --gtk option on command line (unless other related
options are not given).

$ cat ~/.perfconfig
[gtk]
report = true

Cc: Pekka Enberg 
Signed-off-by: Namhyung Kim 
---
 tools/perf/perf.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/tools/perf/perf.c b/tools/perf/perf.c
index a0ae2902f9c9..0f661fbce6a8 100644
--- a/tools/perf/perf.c
+++ b/tools/perf/perf.c
@@ -85,21 +85,26 @@ int check_pager_config(const char *cmd)
return c.val;
 }
 
-static int tui_command_config(const char *var, const char *value, void *data)
+static int browser_command_config(const char *var, const char *value, void 
*data)
 {
struct pager_config *c = data;
if (!prefixcmp(var, "tui.") && !strcmp(var + 4, c->cmd))
c->val = perf_config_bool(var, value);
+   if (!prefixcmp(var, "gtk.") && !strcmp(var + 4, c->cmd))
+   c->val = perf_config_bool(var, value) ? 2 : 0;
return 0;
 }
 
-/* returns 0 for "no tui", 1 for "use tui", and -1 for "not specified" */
-static int check_tui_config(const char *cmd)
+/*
+ * returns 0 for "no tui", 1 for "use tui", 2 for "use gtk",
+ * and -1 for "not specified"
+ */
+static int check_browser_config(const char *cmd)
 {
struct pager_config c;
c.cmd = cmd;
c.val = -1;
-   perf_config(tui_command_config, );
+   perf_config(browser_command_config, );
return c.val;
 }
 
@@ -302,7 +307,7 @@ static int run_builtin(struct cmd_struct *p, int argc, 
const char **argv)
prefix = NULL; /* setup_perf_directory(); */
 
if (use_browser == -1)
-   use_browser = check_tui_config(p->cmd);
+   use_browser = check_browser_config(p->cmd);
 
if (use_pager == -1 && p->option & RUN_SETUP)
use_pager = check_pager_config(p->cmd);
-- 
1.7.11.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: acked-by meaning

[Randy Dunlap]

On 11/11/2012 05:40 PM, Thiago Farina wrote:

> Hi,
> 
> What is the meaning of 'Acked-by:' line? Is the same of LGTM? How it
> differs from 'Reviewed-by:'?

Reviewed-by: is stronger than Acked-by:.
If someone replies with Reviewed-by, they also accept some
responsibility for fixing any problems that the patch might
introduce after it is merged.
Acked-by just means agreement with the patch.

> If someone acks a patch (can anybody acks or just the maintainer?),
> does it mean that he will also apply the patch to his tree?


Anybody can reply to a patch with Acked-by.
No, it doesn't mean that the replying/acking person will apply
the patch to any tree.


Have you read what Documentation/SubmittingPatches and
Documentation/development-process/5.Posting and 6.Followthrough
say about Acked-by?

-- 
~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: Is this a kernel bug?

[Cyberman Wu]

On Fri, Nov 9, 2012 at 9:11 AM, Tejun Heo  wrote:
> Hello,
>
> On Fri, Nov 09, 2012 at 08:53:49AM +0800, Cyberman Wu wrote:
>> A lot of these message on many CPU:
>
> What I'm really curious about is the *first* exception.
>
> Is the following the first one?  Some lines (why the stackdump is
> happening) are missing at the top.

It's really the first one. The taskdump is happening because on Gx it
don't solve
unaligned access on hardware, but software, and it unaligned access occurred
in kernel space and it not occurred while get_user() or put_user(),
the exception
handler will dump these things and try to kill that process group causing that
exception.
The second exception occurred while that first exception handler trying to kill
kworker kernel thread.
>
>>  Pid: 906, comm: kworker/16:1, CPU: 16
> ...
>>  pc : 0xfff7002fc488 ex1: 1 faultnum: 17
>>
>> Starting stack dump of tid 906, pid 906 (kworker/16:1) on cpu 16 at
>> cycle 416925425702833
>>   frame 0: 0xfff7002fc488 worker_enter_idle+0x1c8/0x2e8 (sp
>> 0xfe00f9fbfe78)
>>   frame 1: 0xfff7002750c8 worker_thread+0x4c8/0x898 (sp 
>> 0xfe00f9fbfea0)
>>   frame 2: 0xfff7000f0530 kthread+0xe0/0xe8 (sp 0xfe00f9fbff80)
>>   frame 3: 0xfff7000bab38 start_kernel_thread+0x18/0x20 (sp
>
> Is it triggering one of BUG_ON() in worker_enter_idle()?  Can you map
> the pc to the source line number using addr2line?

Instead of using addr2line, I disassembled the whole function and analyzed it,
exception occurred while function try to load return address from
address pointer by
r2 into LR.
>
>> The first exception is platform specific and should be a hardware error:
>> fff7002fc480:   180906cfc0128d82{ addi r2, sp, 40 ;
>> addi r31, sp, 32 }
>> fff7002fc488:   87b886ca04218d95{ addi r21, sp, 24 ;
>> addi r20, sp, 16 ; ld lr, r2 }
>> While 'ld lr, r2' executed, r2 should be sp+40, but it value is 2.
>> I've analysis the execute
>> snap shot and:
>> 1. r2 should be 2 before 'addi r2, sp, 40' executed.
>> 2. r0's value is sp+40 when exception ocurred, but it shouldn't be
>> that value following
>> executing flow in that function.
>> So it seems while 'addi r2, sp 40' be executed, what it really
>> executed is 'addi r0, sp, 40',
>> maybe the instruction was load with a bit reverted for memory error,
>> or cache error or
>> problem of CPU? I'm not sure since it never occurred again.
>
> So, the first exception wasn't a software bug?

I don't think it a software bug, since the exception flow and shouldn't
generate that register snapshot.
>
>> What I thought maybe a kernel bug is that second exception. I've
>> simulated it try to
>> generate a exception in kworker, and it occurred again. Then I checked
>> the code and
>
> After a fatal exception in kernel space, nothing is guaranteed to
> work.  It's usually in the realm of "if it limps along, great;
> otherwise, too bad", so it isn't really a bug.  There are only so many
> things you can do after a program segfaults after all.  That said, it
> might be a good idea to clear PF_WQ_WORKER from do_exit() so that at
> least we can avoid oops from irq context after a work item messes up.
>
> Thanks.
>
> --
> tejun



-- 
Cyberman Wu
--
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: Auto reboot when CPU at full load with X86_ACPI_CPUFREQ

[Drunkard Zhang]

2012/11/12 Pavel Machek :
> Hi!
>
>> I'm using Intel Xeon X5570 x2 with Asus Z8PE-D18, and experiencing
>> auto reboot when CPU full loaded for minutes, like building kernel
>> with "make -j17". After a lot of bisecting of config file, I found the
>> option leads to the reboot: X86_ACPI_CPUFREQ, both configed
>> X86_ACPI_CPUFREQ as a module or built in will lead to reboot.
>>
>> Config file finally bisected appended, config-3.7.0-rc3+-bad is the
>> one leads to reboot, config-3.7.0-rc3+-ok works OK. Hardware info also
>> appended.
>>
>> I think it is a bug, anything I can do? When the bug triggered, the
>> screen blanked immediately, any advice for me to debug? Happy to match
>> to code :-)
>>
>> This bug is CPU specific, with Xeon E5606 or E5620 it's all fine, just
>> triggered with Xeon X5570, or maybe all Xeon X serial.
>>
>> Tested kernel version: 3.1.x, 3.3.x, 3.5.x, 3.6.x, 3.7*, they are all 
>> affected.
>
> What does temperature do during those runs?
> Pavel

CPU temperature didn't over 60 by degrees. I'm sure it's not hardware
faults, because without X86_ACPI_CPUFREQ it works fine, built in or
load as module it will reboot. I also configured some debug options to
catch something, but the reboot is too fast, dam. Any sugests?
--
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 10/21] perf hists: Introduce hists__link

[Namhyung Kim]

On Fri,  9 Nov 2012 18:42:59 -0300, Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo 
>
> That given two hists will find the hist_entries (buckets) in the second
> hists that are for the same bucket in the first and link them, then it
> will look for all buckets in the second that don't have a counterpart in
> the first and will create a dummy counterpart that will then be linked
> to the entry in the second.
>
> For multiple events this will be done pairing the leader with all the
> other events in the group, so that in the end the leader will have all
> the buckets in all the hists in a group, dummy or not while the other
> hists will be left untouched.
[snip]
> + he = hist_entry__new(pair);
> + if (he) {
> + he->stat.nr_events = 0;
> + he->stat.period= 0;

What about other fields?
Why not use "memset(>stat, 0, sizeof(he->stat))" for this?

Thanks,
Namhyung


> + he->hists  = hists;
> + rb_link_node(>rb_node, parent, p);
> + rb_insert_color(>rb_node, >entries);
> + hists__inc_nr_entries(hists, he);
> + }
> +out:
> + return he;
> +}
> +
--
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: [BUGFIX] PM: Fix active child counting when disabled and forbidden

[Alan Stern]

On Mon, 12 Nov 2012, Huang Ying wrote:

> > The first question: How should the PCI subsystem prevent the parents of 
> > driverless VGA devices from being runtime suspended while userspace is 
> > accessing them?
> 
> I think Rafael's patch is good for that.

But his patch isn't needed if we make these other changes.

> > The second question: Should the PM core allow devices that are disabled
> > for runtime PM to be in the SUSPENDED state when
> > dev->power.runtime_auto is clear?
> 
> I think that should not be allowed.

Disallowing it is okay with me too.  But it will require several 
changes to the code, more than what your patch did.

> > Assuming we don't want to allow this, there's a third question: Should
> > pm_runtime_allow call pm_runtime_set_suspended if the device is
> > disabled?
> 
> Is it absolute necessary to call pm_runtime_set_suspended?  If the
> device is disabled, the transition to SUSPENDED state will not be
> triggered even if the device is ACTIVE.

It's not absolutely necessary to do this, but we ought to because it 
will allow the device's parent to be suspended.  If we leave the device 
in the ACTIVE state then the parent can't be suspended, even when the 
device is disabled.

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 0/8] Fix coding style in sdhci.c

[Jaehoon Chung]

Hi Tushar,

Could you make one patch? Why do you separate patches?

Best Regards,
Jaehoon Chung

On 11/09/2012 08:39 PM, Tushar Behera wrote:
> Documents/CodingStyle Chapter 3 recommends usage of braces for both
> if and else statements if any of the branches contains multiple
> statements.
> 
> Cleaning up drivers/mmc/host/sdhci.c for all these occurrences.
> 
> Tushar Behera (8):
>   mmc: sdhci: fix coding style in sdhci_calc_timeout
>   mmc: sdhci: fix coding style in sdhci_set_transfer_mode
>   mmc: sdhci: fix coding style in sdhci_finish_data
>   mmc: sdhci: fix coding style in sdhci_set_clock
>   mmc: sdhci: fix coding style in sdhci_do_set_ios
>   mmc: sdhci: fix coding style in sdhci_execute_tuning
>   mmc: sdhci: fix coding style in sdhci_data_irq
>   mmc: sdhci: fix coding style in sdhci_add_host
> 
>  drivers/mmc/host/sdhci.c |   58 +
>  1 files changed, 32 insertions(+), 26 deletions(-)
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL 00/21] perf/core improvements and fixes

[Namhyung Kim]

Hi Arnaldo,

On Fri,  9 Nov 2012 18:42:49 -0300, Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
>   Please consider pulling.
>
> - Arnaldo
>
> The following changes since commit 8dfec403e39b7c37fd6e8813bacc01da1e1210ab:
>
>   perf tests: Removing 'optional' field (2012-11-05 14:03:59 -0300)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux 
> tags/perf-core-for-mingo
>
> for you to fetch changes up to 27f94d52394003d444a383eaf8d4824daf32432e:
>
>   tools lib traceevent: Use 'const' in variables pointing to const strings 
> (2012-11-09 17:42:47 -0300)
>
> 
> perf/core improvements and fixes:
>
> . Add a 'link' method for hists, so that we can have the leader with
>   buckets for all the entries in all the hists.  This new method
>   is now used in the default 'diff' output, making the sum of the 'baseline'
>   column be 100%, eliminating blind spots. Now we need to use this
>   for 'diff' with > 2 perf.data files and for multi event 'report' and
>   'annotate'.

I'm not sure it can be used for group report at least in its current
form.  IIUC it connects multiple hist entries using a list head and
create a dummy entry in the leader if need be.  But it didn't handle
non-leader entries so it's hard to tell which is which if less entries
are present only.  For example consider following case:

leader  member1 member2
A   A   A
B
C
D

where leader, member1 and member2 are evsel/hists and A, B, C and D are
hist entries.  After 'linking' the entries the leader will have
following linkage:

leader
A   ->  A   ->  A
B
C (dummy) ->C
D (dummy)   ->  D

In this case, for entry A the leader can determine which entry came from
which hists by looking its order in the list.  For entry B the leader
can use zero value for them since the list is empty.  However for
entries C and D, it cannot know which one is the right hists unless it
records a hist index or creates dummy entry and insert it in a correct
order (looks far from an optimal solution).  Am I missing something?

Thanks,
Namhyung
--
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 7/9] trace: use this_cpu_ptr per-cpu helper

[Shan Wei]

Christoph Lameter said, at 2012/11/10 4:15:
> On Fri, 9 Nov 2012, Shan Wei wrote:
> 
>> -return buffer->buffer;
>> +return (char *)this_cpu_ptr(_buffer->buffer);
>>  }
> 
> Add a comment to explain the cast?

typeof() is a pointer to array of 1024 char, or char (*)[1024].
But, typeof([0]) is a pointer to char which match the return type of 
get_trace_buf().
As well-known, the value of  is equal to [0].
so return this_cpu_ptr(_buffer->buffer[0]) can avoid this cast. 

I will submit v4 version patch which improve it.

Thanks~
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/2] pinctrl: mxs: Make PINCTRL_MXS select PINMUX && PINCONF

[Axel Lin]

Then we can remove "select PINMUX && PINCONF" from PINCTRL_IMX{23,28}.
This simplifies the dependency.

Signed-off-by: Axel Lin 
Acked-by: Shawn Guo 
---
 drivers/pinctrl/Kconfig |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 007704f..0074873 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -100,17 +100,15 @@ config PINCTRL_MMP2
 
 config PINCTRL_MXS
bool
+   select PINMUX
+   select PINCONF
 
 config PINCTRL_IMX23
bool
-   select PINMUX
-   select PINCONF
select PINCTRL_MXS
 
 config PINCTRL_IMX28
bool
-   select PINMUX
-   select PINCONF
select PINCTRL_MXS
 
 config PINCTRL_NOMADIK
-- 
1.7.9.5



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/2] pinctrl: tegra: Make PINCTRL_TEGRA select PINMUX && PINCONF

[Axel Lin]

Then we can remove "select PINMUX && PINCONF" from PINCTRL_TEGRA{20,30}.
This simplifies the dependency.

Signed-off-by: Axel Lin 
---
 drivers/pinctrl/Kconfig |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 6d5a50b..007704f 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -158,17 +158,15 @@ config PINCTRL_SIRF
 
 config PINCTRL_TEGRA
bool
+   select PINMUX
+   select PINCONF
 
 config PINCTRL_TEGRA20
bool
-   select PINMUX
-   select PINCONF
select PINCTRL_TEGRA
 
 config PINCTRL_TEGRA30
bool
-   select PINMUX
-   select PINCONF
select PINCTRL_TEGRA
 
 config PINCTRL_U300
-- 
1.7.9.5



--
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 3/9] net: xfrm: use __this_cpu_read per-cpu helper

[Shan Wei]

Christoph Lameter said, at 2012/11/10 4:12:
> On Fri, 9 Nov 2012, Shan Wei wrote:
> 
>> v3 fix compile warning:
>> net/xfrm/xfrm_ipcomp.c: In function 'ipcomp_alloc_tfms':
>> net/xfrm/xfrm_ipcomp.c:285: warning: assignment from incompatible pointer 
>> type
> 
> Why exactly is the pointer type not compatible? Looks like we have a
> problem here.
> 

pos->tfms(struct crypto_comp **tfms) is a double pointer that point to struct 
crypto_comp.
returned value is a pointer that point to struct crypto_comp;
So, we need to dereference and then read.

+ tfm = __this_cpu_read(*pos->tfms);

I will update this patch in v4 to fix it.

Thanks~
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] dt/platform: Use cell-index for device naming if available

[Stepan Moskovchenko]

> On Sun, Nov 11, 2012 at 2:32 AM, Rob Herring 
> wrote:
>> On 11/09/2012 06:48 PM, Stepan Moskovchenko wrote:
>>> Use the cell-index property to construct names for platform
>>> devices, falling back on the existing scheme of using the
>>> device register address if cell-index is not specified.
>>>
>>> The cell-index property is a more useful device identifier,
>>> especially in systems containing several numbered instances
>>> of a particular hardware block, since it more easily
>>> illustrates how devices relate to each other.
>>>
>>> Additionally, userspace software may rely on the classic
>>> . naming scheme to access device attributes in
>>> sysfs, without having to know the physical addresses of
>>> that device on every platform the userspace software may
>>> support. Using cell-index for device naming allows the
>>> device addresses to be hidden from userspace and to be
>>> exposed by logical device number without having to rely on
>>> auxdata to perform name overrides. This allows userspace to
>>> make assumptions about which sysfs nodes map to which
>>> logical instance of a specific hardware block.
>>>
>>> Signed-off-by: Stepan Moskovchenko 
>>> ---
>>> I had also considered using something like the linux,label property to
>>> allow
>>> custom names for platform devices without resorting to auxdata, but the
>>> cell-index approach seems more in line with what cell-index was
>>> intended for
>>> and with what the pre-DT platform device naming scheme used to be.
>>> Please let
>>> me know if you think there is a better way to accomplish this.
>>>
>>> This is just being sent out as an RFC for now. If there are no
>>> objections, I
>>> will send this out as an official patch, along with (or combined with)
>>> a patch
>>> to fix up the device names in things like clock tables of any affected
>>> platforms.
>>
>> cell-index is basically deprecated. This has been discussed multiple
>> times in the past. You can use auxdata if you really need to have the
>> old name.
>
> Actually, I think it would be fine to use an /aliases entry to set the
> device name. That's the place to put global namespace information.
>
> g.
>

Ah, thank you. I would prefer to stay away from auxdata, since it involves
placing more platform-specific data into the kernel, and it is my
understanding that auxdata is intended as a temporary measure. The
/aliases approach looks interesting, and I'll see what I can do with it -
hopefully I can have an RFC / patch soon. It looks like we would want an
"inverse" alias lookup- that is, we would need to know which alias
corresponds to a given node. Is it possible for a node to have multiple
aliases? If so, which shall we use to create the device name? Anyway, I
will further look into how these aliases work.

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: [PATCH 3/3] ipgre: capture inner headers during encapsulation

[Joseph Gasparakis]

On Sun, 11 Nov 2012, Dmitry Kravkov wrote:

> On Thu, 2012-11-08 at 18:18 -0800, Joseph Gasparakis wrote:
> >  
> > if (skb->ip_summed == CHECKSUM_PARTIAL &&
> > skb_checksum_help(skb))
> > @@ -902,6 +903,17 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff 
> > *skb, struct net_device *dev
> > tunnel->err_count = 0;
> > }
> >  
> > +   offset = skb->data - skb->head;
> > +
> > +   skb_reset_inner_mac_header(skb);
> > +
> > +   if (skb->network_header)
> > +   skb_set_inner_network_header(skb, skb->network_header - offset);
> > +
> > +   if (skb->transport_header)
> > +   skb_set_inner_transport_header(skb, skb->transport_header -
> > +  offset);
> > +
> > max_headroom = LL_RESERVED_SPACE(tdev) + gre_hlen + rt->dst.header_len;
> >  
> > if (skb_headroom(skb) < max_headroom || skb_shared(skb)||
> 
> How it will be useful if skb_checksum_help(skb) will calculate csum? And
> leaves nothing to offload 
>
Thanks for catching this Dmitry. Will fix it in v2 
--
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] nfs: Fix wrong slab cache in nfs_commit_mempool

[ycnian]

From: Yanchuan Nian 

The slab cache in nfs_commit_mempool is wrong, and I think it is just a slip.
I tested it on a x86-32 machine, the size of nfs_write_header is 544, and
the size of nfs_commit_data is 408, so it works fine. It is also true that
sizeof(struct nfs_write_header) > sizeof(struct nfs_commit_data) on other
platforms in my opinoin. Just fix it.

Signed-off-by: Yanchuan Nian 
---
 fs/nfs/write.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/nfs/write.c b/fs/nfs/write.c
index 9347ab7..f710e39 100644
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -1829,7 +1829,7 @@ int __init nfs_init_writepagecache(void)
goto out_destroy_write_mempool;
 
nfs_commit_mempool = mempool_create_slab_pool(MIN_POOL_COMMIT,
- nfs_wdata_cachep);
+ nfs_cdata_cachep);
if (nfs_commit_mempool == NULL)
goto out_destroy_commit_cache;
 
-- 
1.7.4.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 2/2] pinctrl: mxs: Make PINCTRL_MXS select PINMUX && PINCONF

[Shawn Guo]

On Sun, Nov 11, 2012 at 10:22:42AM +0800, Axel Lin wrote:
> Then we can remove "select PINMUX && PINCONF" from PINCTRL_IMX{23,28}.
> This simplifies the dependency.
> 
> Signed-off-by: Axel Lin 
> ---
>  drivers/pinctrl/Kconfig |6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
> index fc0f49a..d5c9431 100644
> --- a/drivers/pinctrl/Kconfig
> +++ b/drivers/pinctrl/Kconfig
> @@ -99,18 +99,16 @@ config PINCTRL_MMP2
>   select PINCONF
>  
>  config PINCTRL_MXS
> + select PINMUX
> + select PINCONF

Better have them after 'bool' below, otherwise,

Acked-by: Shawn Guo 

>   bool
>  
>  config PINCTRL_IMX23
>   bool
> - select PINMUX
> - select PINCONF
>   select PINCTRL_MXS
>  
>  config PINCTRL_IMX28
>   bool
> - select PINMUX
> - select PINCONF
>   select PINCTRL_MXS
>  
>  config PINCTRL_NOMADIK
> -- 
> 1.7.9.5
> 
> 
> 

--
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: scsi target, likely GPL violation

[Douglas Gilbert]

On 12-11-11 04:34 AM, James Bottomley wrote:

On Wed, 2012-11-07 at 08:50 -0800, Andy Grover wrote:

Nick,

Your company appears to be shipping kernel features in RTS OS that are
not made available under the GPL, specifically support for the
EXTENDED_COPY and COMPARE_AND_WRITE SCSI commands, in order to claim
full Vmware vSphere 5 VAAI support.

http://www.risingtidesystems.com/storage.html
http://www.linux-iscsi.org/wiki/VAAI

Private emails to you and RTS CEO Marc Fleischmann have not elicited a
useful response.

You are subsystem maintainer for the in-kernel SCSI target support
(drivers/target/*), and your company appears to be violating the GPL.
Please explain.


Can we please cool it with the inflammatory accusations.  Please
remember that statements which damage or seek to damage the reputation
of a company amount to libel even under US law ... and using phrases
like "appears to" doesn't shield you from this.

I also note that whatever their website says RTS OS isn't in VMware's
certified compatibility list:

http://www.vmware.com/resources/compatibility/pdf/vi_io_guide.pdf

Plus it's a grey area what you actually have to support to make that
list (especially as XCOPY has now been removed from SBC-3 in favour of
token copy), so I'd say that the chain of reasoning you've used to come
up with this hearsay allegation of copyright violation is tenuous at
best.


The SCSI EXTENDED COPY command (also known by the abbreviation "XCOPY")
is specified in the SPC (SCSI Primary Commands) series of standards, not
the SBC (SCSI Block Commands) series. Yes, it has been enhanced in the
SPC-4 drafts (what you term as "token copy") but as far as I can
determine, still allows for the original EXTENDED COPY command usage.
EXTENDED COPY was first standardized in SPC-2 (ANSI INCITS 351-2001) in
2001. The most recent SPC standard is SPC-3 (ANSI INCITS 408-2005) and
if VMWare don't mention some other SCSI standard or draft, then the
SPC-3 specification of the EXTENDED COPY command should be the
reference. And that is prior to the addition of the "token copy"
functionality.

The latest released version of my sg3_utils package (1.34) contains
a contributed sg_xcopy utility that invokes the SCSI EXTENDED COPY
command. At this time it does not support the recently added "token
copy" functionality.


Anybody who does enforcement will tell you that you begin with first
hand proof of a violation.  That means obtain the product and make sure
it's been modified and that a request for corresponding source fails.
In this case, since I presume Red Hat, as a RTS partner, has a bona fide
copy of the RTS OS, please verify it does indeed implement or issue the
commands which are not in the public git repository and that whoever
owns the copy makes a request for the source code.

I would really appreciate it if the next email I see from you on this
subject is either

  1. Yes, I've got first hand proof of a GPL violation (in which case
 we'll then move to seeing how we can remedy this) or
  2. A genuine public apology for the libel, which I'll do my best to
 prevail on RTS to accept.


Sorry to add another category.

Doug Gilbert


Because any further discussion of unsubstantiated allegations of this
nature exposes us all to jeopardy of legal sanction.

James


--
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: [BUGFIX] PM: Fix active child counting when disabled and forbidden

[Huang Ying]

On Fri, 2012-11-09 at 11:41 -0500, Alan Stern wrote:
> On Fri, 9 Nov 2012, Huang Ying wrote:
> 
> > On Thu, 2012-11-08 at 12:07 -0500, Alan Stern wrote:
> > > On Thu, 8 Nov 2012, Rafael J. Wysocki wrote:
> > > 
> > > > > > > is it a good idea to allow to set device state to SUSPENDED if 
> > > > > > > the device
> > > > > > > is disabled?
> > > > > > 
> > > > > > No, it is not.  The status should always be ACTIVE as long as 
> > > > > > usage_count > 0.
> > > 
> > > That isn't strictly true, because pm_runtime_get_noresume violates this
> > > rule.  What the PM core actually does is prevent a transition from the
> > > ACTIVE state to the SUSPENDING/SUSPENDED state if usage_count > 0,
> > > _provided_ runtime PM is enabled.  There's no such restriction when it
> > > is disabled.
> > 
> > Usage count may be not a issue for the end user.  But "on" in "control"
> > sysfs file + SUSPENDED can be confusing for the end user.  Maybe we need
> > to check dev->power.runtime_auto in pm_runtime_set_suspended().
> 
> You are confusing the issue by raising two separate (though related)
> questions.

Thanks for clarify.

> The first question: How should the PCI subsystem prevent the parents of 
> driverless VGA devices from being runtime suspended while userspace is 
> accessing them?

I think Rafael's patch is good for that.

> The second question: Should the PM core allow devices that are disabled
> for runtime PM to be in the SUSPENDED state when
> dev->power.runtime_auto is clear?

I think that should not be allowed.

> Assuming we don't want to allow this, there's a third question: Should
> pm_runtime_allow call pm_runtime_set_suspended if the device is
> disabled?

Is it absolute necessary to call pm_runtime_set_suspended?  If the
device is disabled, the transition to SUSPENDED state will not be
triggered even if the device is ACTIVE.

Best Regards,
Huang Ying


--
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: build failure after merge of the v4l-dvb tree

[Stephen Rothwell]

Hi Mauro,

After merging the v4l-dvb tree, today's linux-next build (x86_64
allmodconfig) failed like this:

ERROR: "sms_ir_exit" [drivers/media/common/siano/smsmdtv.ko] undefined!
ERROR: "sms_ir_event" [drivers/media/common/siano/smsmdtv.ko] undefined!
ERROR: "sms_ir_init" [drivers/media/common/siano/smsmdtv.ko] undefined!

This is better than Friday, but still not quite there. :-(

I have used the v4l-dvb tree from next-20121026 again.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpmAz4484BVi.pgp
Description: PGP signature

Re: [PATCH] mfd/DA9055: Remove Unicode Byte Order Marks

[Samuel Ortiz]

Hi Geert,

On Mon, Oct 15, 2012 at 10:44:45PM +0200, Geert Uytterhoeven wrote:
> Older gcc (< 4.4) doesn't like files starting with Unicode BOMs:
> 
> include/linux/mfd/da9055/core.h:1: error: stray ‘\357’ in program
> include/linux/mfd/da9055/core.h:1: error: stray ‘\273’ in program
> include/linux/mfd/da9055/core.h:1: error: stray ‘\277’ in program
> include/linux/mfd/da9055/pdata.h:1: error: stray ‘\357’ in program
> include/linux/mfd/da9055/pdata.h:1: error: stray ‘\273’ in program
> include/linux/mfd/da9055/pdata.h:1: error: stray ‘\277’ in program
> include/linux/mfd/da9055/reg.h:1: error: stray ‘\357’ in program
> include/linux/mfd/da9055/reg.h:1: error: stray ‘\273’ in program
> include/linux/mfd/da9055/reg.h:1: error: stray ‘\277’ in program
> 
> Remove the BOMs, the rest of the files is plain ASCII anyway.
> 
> Output of "file" before:
> 
> include/linux/mfd/da9055/core.h:  UTF-8 Unicode (with BOM) C program text
> include/linux/mfd/da9055/pdata.h: UTF-8 Unicode (with BOM) C program text
> include/linux/mfd/da9055/reg.h:   UTF-8 Unicode (with BOM) C program text
> 
> Output of "file" after:
> 
> include/linux/mfd/da9055/core.h:  ASCII C program text
> include/linux/mfd/da9055/pdata.h: ASCII C program text
> include/linux/mfd/da9055/reg.h:   ASCII C program text
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
>  include/linux/mfd/da9055/core.h  |2 +-
>  include/linux/mfd/da9055/pdata.h |2 +-
>  include/linux/mfd/da9055/reg.h   |2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
Applied to my for-next branch, thanks.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
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 v7 0/3] Add modules to support realtek PCIE card reader

[Samuel Ortiz]

Hi Chris,

On Fri, Nov 09, 2012 at 10:34:48AM -0500, Chris Ball wrote:
> Hi,
> 
> On Fri, Nov 09 2012, wwang wrote:
> > I have noticed that the file rtsx_pci_sdmmc.c in your mmc-next branch
> > is still v6 patch.  In v7 patch, this MMC part has also been modified
> > to comply with my MFD portion.  So please update to this version.
> >
> > And one more question. Samuel have merged all of my patch set in his
> > for-next branch, including the MMC part.  I don't know whether this
> > will conflict with your tree in the next merge.
> >
> > Hi Samuel:
> >
> > Since the whole patch set has been merged in your for-next branch,
> > does it mean that you will help to merge all of the three parts to
> > linus's tree?
> 
> I've removed the patch from my tree to avoid conflicting with Samuel.
> I'm happy to either have the MMC patch go through the MFD tree with:
> 
> Acked-by: Chris Ball 
> 
> or to merge the MMC side of v7 myself, whichever Samuel prefers.
I'm taking the patch through my tree, thanks for the ACK.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
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: XHCI: xhci-ring: Remove unused dma address calculation in inc_enq and inc_deq function

[Yuhong Bao]

> It looks like your mail client attempted to line wrap it. You might
> want to use mutt, thunderbird, or maybe even the plain text gmail
> interface to resend this.
If anyone is using Outlook, see this:
https://lkml.org/lkml/2011/1/25/587

Yuhong Bao--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/8] mfd: Batch together MFD related patches

[Samuel Ortiz]

Hi Lee,

On Mon, Nov 05, 2012 at 04:10:28PM +0100, Lee Jones wrote:
> Hi Sam,
> 
> I know you've been busy giving NFC presentations at ELC, but ... :)
> 
> All these patches have been on the list in various other patch-sets
> for some time and have been reviewed by some key people already. All
> other patches from the patch-sets have been taken, so I thought I'd
> batch these up for easy review/acceptance.
Thanks, much appreciated.
I applied all of them to my for-next branch. I don't think patch #1 is rc
material though, as it only fixes a boot warning and not an actual bug or
regression.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
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/

[BUG 3.7-rc5] NULL pointer deref when using a pcie-pci bridged pci device and intel-iommu

[Matthew Thode]

System boots with vt-d disabled in bios. Otherwise I get the errors in
the attached log.  I can do whatever testing you need as this system is
not in production yet.  gonna paste the important part here.  Let me
know if you want anything else.

Please CC me directly as I am not subscribed to the LKML.


Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 5124k freed
IOMMU 0 0xfbffe000: using Queued invalidation
IOMMU: Setting RMRR:
IOMMU: Setting identity map for device :00:1d.0 [0xbf7ec000 -
0xbf7f]
IOMMU: Setting identity map for device :00:1d.1 [0xbf7ec000 -
0xbf7f]
IOMMU: Setting identity map for device :00:1d.2 [0xbf7ec000 -
0xbf7f]
IOMMU: Setting identity map for device :00:1d.7 [0xbf7ec000 -
0xbf7f]
IOMMU: Setting identity map for device :00:1a.0 [0xbf7ec000 -
0xbf7f]
IOMMU: Setting identity map for device :00:1a.1 [0xbf7ec000 -
0xbf7f]
IOMMU: Setting identity map for device :00:1a.2 [0xbf7ec000 -
0xbf7f]
IOMMU: Setting identity map for device :00:1a.7 [0xbf7ec000 -
0xbf7f]
IOMMU: Setting identity map for device :00:1d.0 [0xec000 - 0xe]
IOMMU: Setting identity map for device :00:1d.1 [0xec000 - 0xe]
IOMMU: Setting identity map for device :00:1d.2 [0xec000 - 0xe]
IOMMU: Setting identity map for device :00:1d.7 [0xec000 - 0xe]
IOMMU: Setting identity map for device :00:1a.0 [0xec000 - 0xe]
IOMMU: Setting identity map for device :00:1a.1 [0xec000 - 0xe]
IOMMU: Setting identity map for device :00:1a.2 [0xec000 - 0xe]
IOMMU: Setting identity map for device :00:1a.7 [0xec000 - 0xe]
IOMMU: Prepare 0-16MiB unity mapping for LPC
IOMMU: Setting identity map for device :00:1f.0 [0x0 - 0xff]
PCI-DMA: Intel(R) Virtualization Technology for Directed I/O
BUG: unable to handle kernel NULL pointer dereference at 003c
IP: [] pci_get_dma_source+0xf/0x41
PGD 0
Oops:  [#1] SMP
Modules linked in:
CPU 7
Pid: 1, comm: swapper/0 Not tainted 3.7.0-rc5 #1 Penguin Computing
Relion 1751/X8DTU
RIP: 0010:[]  []
pci_get_dma_source+0xf/0x41
RSP: :8806264d1d88  EFLAGS: 00010282
RAX: 813bd3a8 RBX: 8806261d1000 RCX: e8221180
RDX: 818624f0 RSI: 88062635b0c0 RDI: 
RBP: 8806264d1d88 R08: 8806263d6000 R09: 
R10: 8806264d1ca8 R11: 0005 R12: 
R13: 8806261d1098 R14:  R15: 
FS:  () GS:88063f2e() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 003c CR3: 01c0b000 CR4: 07e0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process swapper/0 (pid: 1, threadinfo 8806264d, task
8806264cf910)
Stack:
 8806264d1dc8 815d02c9  8806
 8806264d1dd8 81c64b00 8806261d1098 8806264d1df8
 8806264d1de8 815cd5a4 81c64b00 815cd56a
Call Trace:
 [] intel_iommu_add_device+0x95/0x167
 [] add_iommu_group+0x3a/0x41
 [] ? bus_set_iommu+0x44/0x44
 [] bus_for_each_dev+0x54/0x81
 [] bus_set_iommu+0x3d/0x44
 [] intel_iommu_init+0xae5/0xb5e
 [] ? free_initrd+0x9e/0x9e
 [] ? memblock_find_dma_reserve+0x13f/0x13f
 [] pci_iommu_init+0x16/0x41
 [] ? pci_proc_init+0x6b/0x6b
 [] do_one_initcall+0x7a/0x129
 [] kernel_init+0x139/0x2a2
 [] ? loglevel+0x31/0x31
 [] ? rest_init+0x6f/0x6f
 [] ret_from_fork+0x7c/0xb0
 [] ? rest_init+0x6f/0x6f
Code: ff c1 75 04 ff d0 eb 12 48 83 c2 10 48 8b 42 08 48 85 c0 75 d3 b8
e7 ff ff ff c9 c3 55 48 c7 c2 f0 24 86 81 48 89 e5 eb 24 8b 0a <66> 3b
4f 3c 74 05 66 ff c1 75 13 66 8b 4a 02 66 3b 4f 3e 74 05
RIP  [] pci_get_dma_source+0xf/0x41
 RSP 
CR2: 003c
---[ end trace 5c5a2ceca067e0ec ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009

[ cut here ]
WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule+0x25/0x51()
Hardware name: Relion 1751
Modules linked in:
Pid: 1, comm: swapper/0 Tainted: G  D  3.7.0-rc5 #1
Call Trace:
   [] warn_slowpath_common+0x80/0x98
 [] warn_slowpath_null+0x15/0x17
 [] native_smp_send_reschedule+0x25/0x51
 [] trigger_load_balance+0x1e8/0x214
 [] scheduler_tick+0xd8/0xe1
 [] update_process_times+0x62/0x73
 [] tick_sched_timer+0x7c/0x9b
 [] __run_hrtimer.clone.24+0x4e/0xc1
 [] hrtimer_interrupt+0xc7/0x1ac
 [] smp_apic_timer_interrupt+0x81/0x94
 [] apic_timer_interrupt+0x6a/0x70
   [] ? console_unlock+0x2c2/0x2ed
 [] ? panic+0x189/0x1c5
 [] ? panic+0xee/0x1c5
 [] do_exit+0x357/0x7b2
 [] oops_end+0xb2/0xba
 [] no_context+0x266/0x275
 [] __bad_area_nosemaphore+0x1bb/0x1db
 [] ? sysfs_addrm_finish+0x2f/0xa6
 [] bad_area_nosemaphore+0xe/0x10
 [] __do_page_fault+0x360/0x39f
 [] ? ida_get_new_above+0xf9/0x19e
 [] ? slab_node+0x59/0xa2
 [] ? mutex_unlock+0x9/0xb
 [] ? 

Re: 3.7.0-rc4 build failure on alpha: MPILIB

[Bob Tracy]

On Mon, Nov 05, 2012 at 07:53:13AM -0600, Bob Tracy wrote:
> With digital signature verification support (SIGNATURE, MPILIB) enabled
> on the Alpha platform, I get the following during the MODPOST section of
> the build:
> 
> ERROR: "__udiv_qrnnd" [lib/mpi/mpi.ko] undefined!
> 
> Current compiler is gcc-4.6.3

Got a workaround.  I'll leave it to the "powers that be" for a proper
fix.  Issue is "__udiv_qrnnd" is part of "arch/alpha/math-emu" and is
built-in.  If MPILIB is built as a module, you get the undefined symbol
error.  If "CONFIG_MPILIB=y" (built-in), no undefined symbol issue.

My best guess is, the proper solution will involve either tightening the
configuration dependencies a bit, or making sure required symbols are
properly exported for use by modules.

-- 

Bob Tracy  |  "Build a man a fire, he'll be warm for a day.  Set
r...@frus.com   |   a man on fire, he'll be warm for the rest of his
   |   life."   -- David Burge (Iowahawk)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] dmatest: Fix NULL pointer dereference on ioat

[Jon Mason]

device_control is an optional and not implemented in all DMA drivers.
Any calls to these will result in a NULL pointer dereference.  dmatest
makes two of these calls when completing the kernel thread and removing
the module.  These are corrected by calling the dmaengine_device_control
wrapper and checking for a non-existant device_control function pointer
there.

Signed-off-by: Jon Mason 
CC: Vinod Koul 
CC: Dan Williams 
---
 drivers/dma/dmatest.c |4 ++--
 include/linux/dmaengine.h |5 -
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
index 24225f0..6ef9465 100644
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -499,7 +499,7 @@ err_srcs:
thread_name, total_tests, failed_tests, ret);
 
/* terminate all transfers on specified channels */
-   chan->device->device_control(chan, DMA_TERMINATE_ALL, 0);
+   dmaengine_terminate_all(chan);
if (iterations > 0)
while (!kthread_should_stop()) {
DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wait_dmatest_exit);
@@ -524,7 +524,7 @@ static void dmatest_cleanup_channel(struct dmatest_chan 
*dtc)
}
 
/* terminate all transfers on specified channels */
-   dtc->chan->device->device_control(dtc->chan, DMA_TERMINATE_ALL, 0);
+   dmaengine_terminate_all(dtc->chan);
 
kfree(dtc);
 }
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index d3201e4..cf94e5f 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -608,7 +608,10 @@ static inline int dmaengine_device_control(struct dma_chan 
*chan,
   enum dma_ctrl_cmd cmd,
   unsigned long arg)
 {
-   return chan->device->device_control(chan, cmd, arg);
+   if (chan->device->device_control)
+   return chan->device->device_control(chan, cmd, arg);
+   else
+   return -ENOSYS;
 }
 
 static inline int dmaengine_slave_config(struct dma_chan *chan,
-- 
1.7.9.5

--
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: scsi target, likely GPL violation

[Dave Airlie]

On Mon, Nov 12, 2012 at 8:41 AM, Julian Calaby  wrote:
> Hi Lawrence,
>
> On Mon, Nov 12, 2012 at 9:13 AM, Lawrence Rosen  wrote:
>> Alan Cox wrote:
>>> So either your work is truely not derivative of the kernel (which I find
>>> wildly improbable) or you have a problem and since you are aware
>>> of the complaints publically I guess probably a triple damages sized
>>> problem. But that's one for your lawyers and whatever opinion they
>>> have on the subject.
>>
>> Hi Alan and others,
>>
>> I've been advising Rising Tide Systems (RTS) in this matter. Please let me
>> reassure you that RTS is acting on advice of counsel.
>
> It's nice to hear from legal counsel on this matter.
>
> I don't think that the *usage* of the kernel APIs is the biggest issue
> here. There are many examples where proprietary code uses these APIs
> and is not violating the GPL.
>
> As I see it, one of the main concerns is because the proprietary and
> in-kernel target systems are, from what I understand, quite similar,
> there is the possibility that GPL licensed contributions to the
> in-kernel target code may have "leaked" into to the proprietary code.
> That said, proving this is a very difficult problem, but the question
> must still be asked:
>
> Can Rising Tide Systems assure us that there is no GPL licensed code
> within their proprietary target code?

Its a bit of both actually.

The problem is if you design a kernel subsystem specifically for the
Linux kernel, even if you use the internal APIs, you are most likely
creating a derived work of the Linux kernel.

questions that would need to be asked:
Can the scsi target code work completely separate from a Linux kernel?
Does it work with another operating system? was it designed for that
operating system?

The whole in-kernel version under the GPL isn't the problem here and
has nothing to do with the violation. Its the one they distribute
separately with their RTS OS kernel, and if they distribute it in one
combined work, then a GPL violation is possibly indicated.

The reasons for non-derived work status that have been suggested (but
not accepted by all the community):
a) AFS, a file system clearly not developed for Linux, where it being
a derived work of something that came after it would be a bit crazy,
b) binary GPU drivers, built from the same source base on their
Windows platform, and the code existed on Windows before Linux,
arguing this driver is a derived work is difficult as well. Also
nvidia specifically don't distribute this driver linked against the
kernel, and distros who have done this in the past have been on the
end of cease-and-desist letters.

So really this is purely a derived work issue, whether they release a
trailing edge version of their code afterwards under the GPL isn't
significant, other than a this might keep the community off our back.

(Yes the secondary issue of people who contributed code and cleanups
back to that code base and if they integrated it back into their
internal code base, is a problem, but I don't believe its the primary
issue).

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 8/7] pppoatm: fix missing wakeup in pppoatm_send()

[Chas Williams (CONTRACTOR)]

In message <1352667081.9449.135.ca...@shinybook.infradead.org>,David Woodhouse 
writes:
>Acked-by: David Woodhouse  for your new
>version of patch #6 (returning DROP_PACKET for !VF_READY), and your
>followup to my patch #8, adding the 'need_wakeup' flag. Which we might
>as well merge into (the pppoatm part of) my patch.
>
>Chas, are you happy with the generic ATM part of that? And the
>nomenclature? I didn't want to call it 'release_cb' like the core socket
>code does, because we use 'release' to mean something different in ATM.
>So I called it 'unlock_cb' instead...

i really would prefer not to use a strange name since it might confuse
larger group of people who are more familiar with the traditional meaning
of this function.  vcc_release() isnt exported so we could rename it if
things get too confusing.

i have to look at this a bit more but we might be able to use release_cb
to get rid of the null push to detach the underlying protocol.  that would
be somewhat nice.
--
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 8/7] pppoatm: fix missing wakeup in pppoatm_send()

[Chas Williams (CONTRACTOR)]

In message <2012110437.ga25...@shrek.podlesie.net>,Krzysztof Mazur writes:
>Any race with testing vcc flags is probably not really important
>because:
>   - vcc_release_async() does not take any lock so this check
> will be always racy so we are probably allowed to send
> new frames until vcc is really closed,

this locking/synchronization is handled in the atm device drivers.
the send and close routines are responsbile for synchronization (yes, i
believe that leads to duplicated code but that is the way it currently is)
--
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: mos7840: remove unused variable

[Ben Hutchings]

On Thu, 2012-11-08 at 18:28 +0100, Johan Hovold wrote:
> Fix warning about unused variable introduced by commit e681b66f2e19fa
> ("USB: mos7840: remove invalid disconnect handling") upstream.
> 
> A subsequent fix which removed the disconnect function got rid of the
> warning but that one was only backported to v3.6.
> 
> Reported-by: Jiri Slaby 
> Cc: stable 
> Signed-off-by: Johan Hovold 
> ---
> 
> This patch against v3.4 also applies to v3.0 (and v3.2).
[...]

Queued up for 3.2, thanks.

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.


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

linux-next: comment on the mips tree

[Stephen Rothwell]

Hi Ralf,

After fetching the mips tree today I had a look at the changes (as I
often do when I fetch all trees) and noticed that today's changes are to
add 6 new patches to your mips-for-linux-next branch and then to merge
another branch (current/for-linus) that contains only those same six
patches.  :-(

You really only needed to do one of those two things - and preferably the
second (assuming that you intend to submit that second branch to Linus
shortly).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp21TPNcpodu.pgp
Description: PGP signature

Re: scsi target, likely GPL violation

[Julian Calaby]

Hi Lawrence,

On Mon, Nov 12, 2012 at 9:13 AM, Lawrence Rosen  wrote:
> Alan Cox wrote:
>> So either your work is truely not derivative of the kernel (which I find
>> wildly improbable) or you have a problem and since you are aware
>> of the complaints publically I guess probably a triple damages sized
>> problem. But that's one for your lawyers and whatever opinion they
>> have on the subject.
>
> Hi Alan and others,
>
> I've been advising Rising Tide Systems (RTS) in this matter. Please let me
> reassure you that RTS is acting on advice of counsel.

It's nice to hear from legal counsel on this matter.

I don't think that the *usage* of the kernel APIs is the biggest issue
here. There are many examples where proprietary code uses these APIs
and is not violating the GPL.

As I see it, one of the main concerns is because the proprietary and
in-kernel target systems are, from what I understand, quite similar,
there is the possibility that GPL licensed contributions to the
in-kernel target code may have "leaked" into to the proprietary code.
That said, proving this is a very difficult problem, but the question
must still be asked:

Can Rising Tide Systems assure us that there is no GPL licensed code
within their proprietary target code?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
--
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] r8169: Removed unused macros from r8169.c

[Francois Romieu]

Dayanidhi Sreenivasan  :
[...]

I have fixed the conflict with the driver in net-next due to removal of
the SafeMtu #define and pushed the result in branch davem-next.r8169 at
git://violet.fr.zoreil.com/romieu/linux

Next time you send a patch, please specify the branch it should apply
to and check it does not conflict.

Thanks.

-- 
Ueimor
--
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] vmxnet3: convert BUG_ON(true) into a simple BUG()

[Ryan Mallon]

On 09/11/12 07:23, Sasha Levin wrote:
> Signed-off-by: Sasha Levin 
> ---
>  drivers/net/vmxnet3/vmxnet3_drv.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c 
> b/drivers/net/vmxnet3/vmxnet3_drv.c
> index 0ae1bcc..7e9622f 100644
> --- a/drivers/net/vmxnet3/vmxnet3_drv.c
> +++ b/drivers/net/vmxnet3/vmxnet3_drv.c
> @@ -1922,7 +1922,7 @@ vmxnet3_free_irqs(struct vmxnet3_adapter *adapter)
>   free_irq(adapter->pdev->irq, adapter->netdev);
>   break;
>   default:
> - BUG_ON(true);
> + BUG();
>   }
>  }

All of the BUG_ON tests in this function look like programming error
assertions. It looks like the worst that would happen is that some irqs
might not be properly released, not the sort of thing that is going to
make the system unstable if you don't bug.

Can't they just be replaced with (for example):

if (WARN_ON(blah))
return;

Or even just:

netdev_err(adapter->netdev, "bad irq type %d for free\n",
intr->type);

~Ryan

--
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: scsi target, likely GPL violation

[Lawrence Rosen]

Alan Cox wrote:
> So either your work is truely not derivative of the kernel (which I find
> wildly improbable) or you have a problem and since you are aware 
> of the complaints publically I guess probably a triple damages sized 
> problem. But that's one for your lawyers and whatever opinion they 
> have on the subject.

Hi Alan and others,

I've been advising Rising Tide Systems (RTS) in this matter. Please let me
reassure you that RTS is acting on advice of counsel.

RTS (and specifically Nicholas Bellinger) wrote the scsi target code and
owns its copyright. We registered that copyright at the Library of Congress.
RTS contributed a version of the scsi target to Linux for distribution under
the GPL. On behalf of Marc Fleischmann, CEO of RTS, I can reassure you that
RTS remains committed to the Linux project and will continue to contribute
to it. We are pleased that RTS software is a part of the Linux distribution
under the GPL.

RTS also has a commercial software business. It distributes versions of its
scsi target code that support features and functions not officially in Linux
(or at least, not yet). That commercial RTS business includes the licensing
of those derivative works of its own code to its own customers. Nothing
whatsoever in the GPL or in the policies of the Linux Foundation prohibits
that.

I would also like to address some comments made on these lists by Andy
Grover and Bradley Kuhn. 

First, I hope that we can tone down the arguments about whether the use of
Linux APIs and headers automatically turns a program into a derivative work
of Linux. I think that argument has been largely debunked in the U.S. in the
recent decision in Oracle v. Google, and in Europe in SAS v. World
Programming. Does anyone here question whether the original work that RTS
contributed to Linux (and that *is* under the GPL) is an original work of
authorship of RTS despite the fact that it links to other GPL code using
headers and APIs?

Second, we are grateful for the efforts that Bradley Kuhn and others put in
to enforce the GPL. As I said above, RTS owns and has registered the
copyright on its scsi target and will enforce it if necessary. So Brad, we
may solicit your assistance if we find any third party who is distributing
an unauthorized non-GPL derivative work of the scsi target now in Linux.
RTS, of course, retains the exclusive right to do so, but no third party can
do so without a license from RTS.

Best regards,

/Larry

P.S. In accordance with my obligations as an attorney when communicating
with a represented person, I am copying attorneys for Red Hat and Linux
Foundation on this email.  If anyone wishes to respond to me, please copy me
directly since I am not subscribed to these lists.

Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com)
3001 King Ranch Rd., Ukiah, CA 95482
Office: 707-485-1242



--
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] dmatest: Fix NULL pointer dereference on ioat

[Jon Mason]

On Sat, Nov 10, 2012 at 09:00:15AM +0530, viresh kumar wrote:
> On Sat, Nov 10, 2012 at 2:27 AM, Jon Mason  wrote:
> > device_control is an optional and not implemented in all DMA drivers.
> > Any calls to these will result in a NULL pointer dereference.  dmatest
> > makes two of these calls when completing the kernel thread and removing
> > the module.  These are corrected by calling the dmaengine_device_control
> > wrapper and checking for a non-existant device_control function pointer
> > there.
> >
> > Signed-off-by: Jon Mason 
> > CC: Vinod Koul 
> > CC: Dan Williams 
> > ---
> >  drivers/dma/dmatest.c |4 ++--
> >  include/linux/dmaengine.h |5 -
> >  2 files changed, 6 insertions(+), 3 deletions(-)
> >
> 
> > diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> > index d3201e4..e0004fb 100644
> > --- a/include/linux/dmaengine.h
> > +++ b/include/linux/dmaengine.h
> > @@ -608,7 +608,10 @@ static inline int dmaengine_device_control(struct 
> > dma_chan *chan,
> >enum dma_ctrl_cmd cmd,
> >unsigned long arg)
> >  {
> > -   return chan->device->device_control(chan, cmd, arg);
> > +   if (chan->device->device_control)
> > +   return chan->device->device_control(chan, cmd, arg);
> > +   else
> > +   return -EINVAL;
> 
> -ENOTSUPP or -ENOSYS ??

ENOSYS makes more sense to me.  I'll send out another version shortly.

Dan, do you want me to send the patch to Greg KH for inclusion in the
stable branches back to v3.2?

Thanks,
Jon

> 
> @Dan: I believe i don't have to send another version now. Correct??
> 
> --
> viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] VSOCK for Linux upstreaming

[Sasha Levin]

On 11/05/2012 01:32 PM, George Zhang wrote:
> Sasha,
> There is a 'brief' implementation notes aboutVSOCK protocol family
> in af_vsock.c. More about user space layer socket programming is from
> VMCI Socket Programming Guide. (remove crosst...@vmware.com for email 
> bouncing).
> thanks,
> George

So all the documentation I see in the VMCI Socket Programming Guide is about
userspace programming, and the documentation in af_vsock.c is all around
implementation considerations.

Is there anything that documents the actual protocol? Just for example, whats
the deal with REQUEST/REQUEST2? it appears like something to deal with legacy
code, but I'd really like to have it documented somewhere instead of trying
to figure how everything works by looking at the code.


Thanks,
Sasha



--
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] snd-ice1712: enable suspend on unknown ICE1724 cards

[Ondrej Zary]

Assume that unknown ICE1724-based cards are AC97-only that can suspend
without any additional card-specific code.

This fixes suspend on Gainward Hollywood@Home 7.1.

Signed-off-by: Ondrej Zary 
---
 sound/pci/ice1712/ice1724.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/sound/pci/ice1712/ice1724.c b/sound/pci/ice1712/ice1724.c
index 5cc3fa5..aebd584 100644
--- a/sound/pci/ice1712/ice1724.c
+++ b/sound/pci/ice1712/ice1724.c
@@ -2363,6 +2363,8 @@ static int __devinit snd_vt1724_read_eeprom(struct 
snd_ice1712 *ice,
}
printk(KERN_WARNING "ice1724: No matching model found for ID 0x%x\n",
   ice->eeprom.subvendor);
+   /* assume AC97-only card which can suspend without additional code */
+   ice->pm_suspend_enabled = 1;
 
  found:
ice->eeprom.size = snd_vt1724_read_i2c(ice, dev, 0x04);
-- 
Ondrej Zary
--
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: Auto reboot when CPU at full load with X86_ACPI_CPUFREQ

[Pavel Machek]

Hi!

> I'm using Intel Xeon X5570 x2 with Asus Z8PE-D18, and experiencing
> auto reboot when CPU full loaded for minutes, like building kernel
> with "make -j17". After a lot of bisecting of config file, I found the
> option leads to the reboot: X86_ACPI_CPUFREQ, both configed
> X86_ACPI_CPUFREQ as a module or built in will lead to reboot.
> 
> Config file finally bisected appended, config-3.7.0-rc3+-bad is the
> one leads to reboot, config-3.7.0-rc3+-ok works OK. Hardware info also
> appended.
> 
> I think it is a bug, anything I can do? When the bug triggered, the
> screen blanked immediately, any advice for me to debug? Happy to match
> to code :-)
> 
> This bug is CPU specific, with Xeon E5606 or E5620 it's all fine, just
> triggered with Xeon X5570, or maybe all Xeon X serial.
> 
> Tested kernel version: 3.1.x, 3.3.x, 3.5.x, 3.6.x, 3.7*, they are all 
> affected.

What does temperature do during those runs? 
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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] Coccinelle: Add api/d_find_alias.cocci.

[Cyril Roelandt]

Ensure that calls to d_find_alias() have a corresponding dput().

Signed-off-by: Cyril Roelandt 
---
 scripts/coccinelle/api/d_find_alias.cocci |   80 +
 1 file changed, 80 insertions(+)
 create mode 100644 scripts/coccinelle/api/d_find_alias.cocci

diff --git a/scripts/coccinelle/api/d_find_alias.cocci 
b/scripts/coccinelle/api/d_find_alias.cocci
new file mode 100644
index 000..639eec7
--- /dev/null
+++ b/scripts/coccinelle/api/d_find_alias.cocci
@@ -0,0 +1,80 @@
+/// Make sure calls to d_find_alias() have a corresponding call to dput().
+//
+// Keywords: d_find_alias, dput
+//
+// Confidence: Moderate
+// URL: http://coccinelle.lip6.fr/
+// Options: -include_headers
+
+virtual context
+virtual org
+virtual patch
+virtual report
+
+@r exists@
+local idexpression struct dentry *dent;
+expression E, E1;
+statement S1, S2;
+position p1, p2;
+@@
+(
+   if (!(dent@p1 = d_find_alias(...))) S1
+|
+   dent@p1 = d_find_alias(...)
+)
+
+<...when != dput(dent)
+when != if (...) { <+... dput(dent) ...+> }
+when != true !dent || ...
+when != dent = E
+when != E = dent
+if (!dent || ...) S2
+...>
+(
+   return <+...dent...+>;
+|
+   return @p2 ...;
+|
+   dent@p2 = E1;
+|
+   E1 = dent;
+)
+
+@depends on context@
+local idexpression struct dentry *r.dent;
+position r.p1,r.p2;
+@@
+* dent@p1 = ...
+  ...
+(
+* return@p2 ...;
+|
+* dent@p2
+)
+
+
+@script:python depends on org@
+p1 << r.p1;
+p2 << r.p2;
+@@
+cocci.print_main("Missing call to dput()",p1)
+cocci.print_secs("",p2)
+
+@depends on patch@
+local idexpression struct dentry *r.dent;
+position r.p2;
+@@
+(
++ dput(dent);
+  return @p2 ...;
+|
++ dput(dent);
+  dent@p2 = ...;
+)
+
+@script:python depends on report@
+p1 << r.p1;
+p2 << r.p2;
+@@
+msg = "Missing call to dput() at line %s."
+coccilib.report.print_report(p1[0], msg % (p2[0].line))
-- 
1.7.10.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] iommu/tegra-smmu.c: fix dentry reference leak in smmu_debugfs_stats_show().

[Cyril Roelandt]

Call to d_find_alias() needs a corresponding dput().

Signed-off-by: Cyril Roelandt 
---
 drivers/iommu/tegra-smmu.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 4167863..4252d74 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -1052,6 +1052,7 @@ static int smmu_debugfs_stats_show(struct seq_file *s, 
void *v)
stats[i], val, offs);
}
seq_printf(s, "\n");
+   dput(dent);
 
return 0;
 }
-- 
1.7.10.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 3/3] ceph: fix dentry reference leak in ceph_encode_fh().

[Cyril Roelandt]

dput() was not called in the error path.

Signed-off-by: Cyril Roelandt 
---
 fs/ceph/export.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/ceph/export.c b/fs/ceph/export.c
index 9349bb3..ca3ab3f 100644
--- a/fs/ceph/export.c
+++ b/fs/ceph/export.c
@@ -56,13 +56,15 @@ static int ceph_encode_fh(struct inode *inode, u32 *rawfh, 
int *max_len,
struct ceph_nfs_confh *cfh = (void *)rawfh;
int connected_handle_length = sizeof(*cfh)/4;
int handle_length = sizeof(*fh)/4;
-   struct dentry *dentry = d_find_alias(inode);
+   struct dentry *dentry;
struct dentry *parent;
 
/* don't re-export snaps */
if (ceph_snap(inode) != CEPH_NOSNAP)
return -EINVAL;
 
+   dentry = d_find_alias(inode);
+
/* if we found an alias, generate a connectable fh */
if (*max_len >= connected_handle_length && dentry) {
dout("encode_fh %p connectable\n", dentry);
-- 
1.7.10.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 0/3] Use dput() after d_find_alias().

[Cyril Roelandt]

Hello,

A call to d_find_alias() needs a corresponding call to dput() in order to avoid
resource leaks.

The first patch is a Coccinelle scripts that looks for missing calls to dput().
The other two patches add calls to dput() where needed.

WBR,
Cyril Roelandt.
--
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 8/7] pppoatm: fix missing wakeup in pppoatm_send()

[David Woodhouse]

On Sun, 2012-11-11 at 19:49 +0100, Krzysztof Mazur wrote:
> 
> In pppoatm_devppp_ioctl() we also don't have sk->sk_lock.slock lock.
> In original patch synchronization was trivial because callback
> from socket lock is used.
> 
> I also though about sharing word with encaps enum - encaps needs only 2 bits,
> but it's ugly.

Yeah, fair enough. It's not the end of the world having it in a separate
word. I was just trying to avoid bloating the structure more than we
needed to.

Acked-by: David Woodhouse  for your new
version of patch #6 (returning DROP_PACKET for !VF_READY), and your
followup to my patch #8, adding the 'need_wakeup' flag. Which we might
as well merge into (the pppoatm part of) my patch.

Chas, are you happy with the generic ATM part of that? And the
nomenclature? I didn't want to call it 'release_cb' like the core socket
code does, because we use 'release' to mean something different in ATM.
So I called it 'unlock_cb' instead...

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature

Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)

[Rob Landley]

  On 11/09/2012 10:28:59 AM, Grant Likely wrote:
On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren  
 wrote:

> On 11/05/2012 01:40 PM, Grant Likely wrote:
I'm not actually opposed to it, but it needs to be done in an elegant
way. The DT data model already imposes more of a conceptual learning
curve than I wish it did and I don't want to make that worse with a
versioning model that is difficult to get ones head around.


Speaking of which...

I want to poke at board emulation in qemu, from scratch. Specifically,  
I want to start with an unpopulated board (just the processor), add a  
block of physical memory and a serial device, and boot an initramfs in  
there with stdin/stdout. Then I want to incrementally add an RTC,  
network card, and three block devices.


I'd like to define this board by giving qemu and the kernel the same  
device tree they can parse, and I'd like to _build_ this device tree so  
I understand what's in it. I'd like to repeat this exercize for arm,  
mips, ppc, x86, x86-64, sparc, sh4, and maybe other boards.


And I'd like to write up an article on doing it as a learning exercise.

Last time I checked, doing this wasn't possible. (qemu couldn't define  
a board by parsing a device tree, the kernel used the device tree as a  
guideline but it only really read data the drivers you linked in were  
expecting, the only documentation about what any of the nodes were was  
was read the other device trees as examples or read the source code of  
the drivers looking for data in the tree...)


Is it a more realistic project now? If so, where would I start? (Once  
upon a time I read the booting-without-of document, back when it lived  
in the ppc directory. It didn't really say what should go in any of the  
nodes.)


Rob--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] perf: need to expose sched_clock to correlate user samples with kernel samples

[Stephane Eranian]

On Sat, Nov 10, 2012 at 3:04 AM, John Stultz  wrote:
> On 10/16/2012 10:23 AM, Peter Zijlstra wrote:
>>
>> On Tue, 2012-10-16 at 12:13 +0200, Stephane Eranian wrote:
>>>
>>> Hi,
>>>
>>> There are many situations where we want to correlate events happening at
>>> the user level with samples recorded in the perf_event kernel sampling
>>> buffer.
>>> For instance, we might want to correlate the call to a function or
>>> creation of
>>> a file with samples. Similarly, when we want to monitor a JVM with jitted
>>> code,
>>> we need to be able to correlate jitted code mappings with perf event
>>> samples
>>> for symbolization.
>>>
>>> Perf_events allows timestamping of samples with PERF_SAMPLE_TIME.
>>> That causes each PERF_RECORD_SAMPLE to include a timestamp
>>> generated by calling the local_clock() -> sched_clock_cpu() function.
>>>
>>> To make correlating user vs. kernel samples easy, we would need to
>>> access that sched_clock() functionality. However, none of the existing
>>> clock calls permit this at this point. They all return timestamps which
>>> are
>>> not using the same source and/or offset as sched_clock.
>>>
>>> I believe a similar issue exists with the ftrace subsystem.
>>>
>>> The problem needs to be adressed in a portable manner. Solutions
>>> based on reading TSC for the user level to reconstruct sched_clock()
>>> don't seem appropriate to me.
>>>
>>> One possibility to address this limitation would be to extend
>>> clock_gettime()
>>> with a new clock time, e.g., CLOCK_PERF.
>>>
>>> However, I understand that sched_clock_cpu() provides ordering guarantees
>>> only
>>> when invoked on the same CPU repeatedly, i.e., it's not globally
>>> synchronized.
>>> But we already have to deal with this problem when merging samples
>>> obtained
>>> from different CPU sampling buffer in per-thread mode. So this is not
>>> necessarily
>>> a showstopper.
>>>
>>> Alternatives could be to use uprobes but that's less practical to setup.
>>>
>>> Anyone with better ideas?
>>
>> You forgot to CC the time people ;-)
>>
>> I've no problem with adding CLOCK_PERF (or another/better name).
>
> Hrm. I'm not excited about exporting that sort of internal kernel details to
> userland.
>
> The behavior and expectations from sched_clock() has changed over the years,
> so I'm not sure its wise to export it, since we'd have to preserve its
> behavior from then on.
>
It's not about just exposing sched_clock(). We need to expose a time source
that is exactly equivalent to what perf_event uses internally. If sched_clock()
changes, then perf_event clock will change too and so would that new time
source for clock_gettime(). As long as everything remains consistent, we are
good.

> Also I worry that it will be abused in the same way that direct TSC access
> is, where the seemingly better performance from the more careful/correct
> CLOCK_MONOTONIC would cause developers to write fragile userland code that
> will break when moved from one machine to the next.
>
The only goal for this new time source is for correlating user-level
samples with
kernel level samples, i.e., application level events with a PMU counter overflow
for instance. Anybody trying anything else would be on their own.

clock_gettime(CLOCK_PERF): guarantee to return the same time source as
that used by the perf_event subsystem to timestamp samples when
PERF_SAMPLE_TIME is requested in attr->sample_type.

> I'd probably rather perf output timestamps to userland using sane clocks
> (CLOCK_MONOTONIC), rather then trying to introduce a new time domain to
> userland.   But I probably could be convinced I'm wrong.
>
Can you get CLOCK_MONOTONIC efficiently and in ALL circumstances without
grabbing any locks because that would need to run from NMI context?
--
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 v4] drivers/tty: Folding Android's keyreset driver in sysRQ

[mathieu . poirier]

From: "Mathieu J. Poirier" 

This patch adds keyreset functionality to the sysrq driver. It
allows certain button/key combinations to be used in order to
trigger device resets.

The first time the key-combo is detected a work function that syncs
the filesystems is scheduled and the kernel rebooted. If all the keys
are released and then pressed again, it calls panic. Reboot on panic
should be set for this to work.

Redefining the '__weak sysrq_keyreset_get_params' function is required
to trigger the feature.  Alternatively keys can be passed to the
driver via the "/sys/module/sysrq" interface.

This functionality comes from the keyreset driver submitted by
Arve Hjønnevåg in the Android kernel.

Cc: a...@android.com
Cc: kernel-t...@android.com
Cc: dmitry.torok...@gmail.com
Cc: john.stu...@linaro.org
Cc: a...@lxorguk.ukuu.org.uk
Signed-off-by: Mathieu Poirier 
---
 drivers/tty/sysrq.c   |  303 +
 include/linux/sysrq.h |2 +
 2 files changed, 305 insertions(+), 0 deletions(-)

diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 05728894..da4f538 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -41,14 +41,29 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
 
+#define KEY_RESET_MAX  20 /* how  many is enough ? */
+int keyreset_param[KEY_RESET_MAX];
+struct mutex sysrq_mutex;
+static struct sysrq_state *sysrq_handle;
+
 /* Whether we react on sysrq keys or just ignore them */
 static int __read_mostly sysrq_enabled = SYSRQ_DEFAULT_ENABLE;
 static bool __read_mostly sysrq_always_enabled;
 
+static struct input_handler sysrq_handler;
+
+/* Keep track of what has been called */
+static atomic_t restart_requested;
+
+
 static bool sysrq_on(void)
 {
return sysrq_enabled || sysrq_always_enabled;
@@ -570,6 +585,15 @@ struct sysrq_state {
struct input_handle handle;
struct work_struct reinject_work;
unsigned long key_down[BITS_TO_LONGS(KEY_CNT)];
+   unsigned long keybit[BITS_TO_LONGS(KEY_CNT)];
+   unsigned long upbit[BITS_TO_LONGS(KEY_CNT)];
+   unsigned long key[BITS_TO_LONGS(KEY_CNT)];
+   int (*reset_fn)(void);
+   int key_down_target;
+   int key_down_ctn;
+   int key_up_ctn;
+   int keyreset_data;
+   int restart_disabled;
unsigned int alt;
unsigned int alt_use;
bool active;
@@ -603,6 +627,80 @@ static void sysrq_reinject_alt_sysrq(struct work_struct 
*work)
}
 }
 
+static void deferred_restart(struct work_struct *dummy)
+{
+   atomic_inc(_requested);
+   sys_sync();
+   atomic_inc(_requested);
+   kernel_restart(NULL);
+}
+static DECLARE_WORK(restart_work, deferred_restart);
+
+static int do_keyreset_event(struct sysrq_state *state,
+unsigned int code, int value)
+{
+   int ret;
+   int processed = 0;
+
+   mutex_lock(_mutex);
+
+   /* Is the code of interest to us */
+   if (!test_bit(code, state->keybit)) {
+   mutex_unlock(_mutex);
+   return processed;
+   }
+
+   /* No need to take care of key up events */
+   if (!test_bit(code, state->key) == !value) {
+   mutex_unlock(_mutex);
+   return processed;
+   }
+
+   /* Record new entry */
+   __change_bit(code, state->key);
+
+   processed = 1;
+
+   if (test_bit(code, state->upbit)) {
+   if (value) {
+   state->restart_disabled = 1;
+   state->key_up_ctn++;
+   } else
+   state->key_up_ctn--;
+   } else {
+   if (value)
+   state->key_down_ctn++;
+   else
+   state->key_down_ctn--;
+   }
+
+   if (state->key_down_ctn == 0 && state->key_up_ctn == 0)
+   state->restart_disabled = 0;
+
+   if (value && !state->restart_disabled &&
+   state->key_down_ctn == state->key_down_target) {
+   state->restart_disabled = 1;
+   if (atomic_read(_requested))
+   panic("keyboard reset failed, %d - panic\n",
+atomic_read(_requested));
+   if (state->reset_fn) {
+   ret = state->reset_fn();
+   atomic_set(_requested, ret);
+   } else {
+   pr_info("keyboard reset\n");
+   schedule_work(_work);
+   atomic_inc(_requested);
+   }
+   }
+
+   mutex_unlock(_mutex);
+
+   /* no need to suppress keyreset characters */
+   state->active = false;
+
+   return processed;
+}
+
 static bool sysrq_filter(struct input_handle *handle,
 unsigned int type, unsigned int code, int value)
 {
@@ -669,6 +767,11 @@ static bool sysrq_filter(struct input_handle *handle,
   

Re: [PATCH Resend V2] dt: add helper function to read u8 & u16 variables & arrays

[Rob Herring]

On 11/11/2012 11:27 AM, Viresh Kumar wrote:
> On 11 November 2012 19:42, Rob Herring  wrote:
>> On 11/06/2012 10:22 PM, viresh kumar wrote:
> 
>>> cluster0: cluster@0 {
>>> +   data1 = <0x50 0x60 0x70>;
>>> +   data2 = <0x5000 0x6000 0x7000>;
>>> +   data3 = <0x5000 0x6000 0x7000>;
>>
>> So there is a mismatch in our assumptions. You are just truncating
>> 32-bit values. I assumed you were using the 8 and 16 bit sizes that are
>> now supported in dts. I don't think we should just truncate values
>> blindly. We have support for specifying 8 and 16 values now so you
>> should use that and define that as part of a binding.
> 
> Sorry couldn't get your point at all :(
> What did you mean by "truncating 32 bit values" and how should we
> tell via DT, that the value passed is 8 bit, 16 bit or 32 bit?
> 

You are trying to retrieve an array of 8 or 16-bit values which are
stored as 32-bit values in dtb. Why not define them in the binding as 8
or 16 bit to begin with. Then there is never any ambiguity about their size.

I don't think the size is stored in the dtb. It is only in the dts. You
need to define the size in the binding definitions and use '/bits/'
annotation. With this the data is packed. Then the array function used
should match what the binding defines.

Rob

--
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] MTD: use SQUASHFS_MAGIC from uapi/linux/magic.h

[Luka Perkov]

Signed-off-by: Luka Perkov 
---
 drivers/mtd/ar7part.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/ar7part.c b/drivers/mtd/ar7part.c
index 9453931..7c057a0 100644
--- a/drivers/mtd/ar7part.c
+++ b/drivers/mtd/ar7part.c
@@ -26,19 +26,16 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
+#include 
+
 #define AR7_PARTS  4
 #define ROOT_OFFSET0xe
 
 #define LOADER_MAGIC1  le32_to_cpu(0xfeedfa42)
 #define LOADER_MAGIC2  le32_to_cpu(0xfeed1281)
 
-#ifndef SQUASHFS_MAGIC
-#define SQUASHFS_MAGIC 0x73717368
-#endif
-
 struct ar7_bin_rec {
unsigned int checksum;
unsigned int length;
-- 
1.8.0

--
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 v11 7/7] mm: add vm event counters for balloon pages compaction

[Rafael Aquini]

On Sat, Nov 10, 2012 at 05:55:38PM +0200, Michael S. Tsirkin wrote:
> > mutex_unlock(>balloon_lock);
> > +   balloon_event_count(COMPACTBALLOONMIGRATED);
> >  
> > return MIGRATEPAGE_BALLOON_SUCCESS;
> >  }
> 
> Looks like any ballon would need to do this.
> Can this  chunk go into caller instead?
>

Good catch. It's done, already (v12 just hit the wild).

Thanks!
-- Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v12 0/7] make balloon pages movable by compaction

[Rafael Aquini]

On Sun, Nov 11, 2012 at 05:01:13PM -0200, Rafael Aquini wrote:
> Change log:
> v12:
>  * Address last suggestions on sorting the barriers usage out  (Mel 
> Gorman);
>  * Fix reported build breakages for CONFIG_BALLOON_COMPACTION=n (Andrew 
> Morton);
>  * Enhance commentary on the locking scheme used for balloon page compaction;
>  * Move all the 'balloon vm_event counter' changes to PATCH 07;

Andrew, 

could you drop the earlier review (v11) and pick this submission (v12) instead,
please?


Aside: before submitting I rebased the series on -next-20121109, after reverting
the v11 commits, to make those clean-up hunks from PATCH 01 apply smoothly.

-- Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pinctrl: pinmux: Release all taken pins in pinmux_enable_setting error paths

[Linus Walleij]

On Sat, Nov 10, 2012 at 2:53 PM, Axel Lin  wrote:

> Currently pinmux_enable_setting does not release all taken pins if
> ops->enable() returns error. This patch ensures all taken pins are
> released in any error paths.
>
> Signed-off-by: Axel Lin 

Thanks a *lot* that's a pretty important fix Axel! :-)

Patch applied.

Yours,
Linus Walleij
--
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 v12 6/7] mm: introduce putback_movable_pages()

[Rafael Aquini]

The PATCH "mm: introduce compaction and migration for virtio ballooned pages"
hacks around putback_lru_pages() in order to allow ballooned pages to be
re-inserted on balloon page list as if a ballooned page was like a LRU page.

As ballooned pages are not legitimate LRU pages, this patch introduces
putback_movable_pages() to properly cope with cases where the isolated
pageset contains ballooned pages and LRU pages, thus fixing the mentioned
inelegant hack around putback_lru_pages().

Signed-off-by: Rafael Aquini 
---
 include/linux/migrate.h |  2 ++
 mm/compaction.c |  6 +++---
 mm/migrate.c| 20 
 mm/page_alloc.c |  2 +-
 4 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index 4ce2ee9..42fafb4 100644
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@ -27,6 +27,7 @@ typedef struct page *new_page_t(struct page *, unsigned long 
private, int **);
 #ifdef CONFIG_MIGRATION
 
 extern void putback_lru_pages(struct list_head *l);
+extern void putback_movable_pages(struct list_head *l);
 extern int migrate_page(struct address_space *,
struct page *, struct page *, enum migrate_mode);
 extern int migrate_pages(struct list_head *l, new_page_t x,
@@ -51,6 +52,7 @@ extern int migrate_misplaced_page(struct page *page, int 
node);
 #else
 
 static inline void putback_lru_pages(struct list_head *l) {}
+static inline void putback_movable_pages(struct list_head *l) {}
 static inline int migrate_pages(struct list_head *l, new_page_t x,
unsigned long private, bool offlining,
enum migrate_mode mode) { return -ENOSYS; }
diff --git a/mm/compaction.c b/mm/compaction.c
index 76abd84..f268bd8 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -995,7 +995,7 @@ static int compact_zone(struct zone *zone, struct 
compact_control *cc)
switch (isolate_migratepages(zone, cc)) {
case ISOLATE_ABORT:
ret = COMPACT_PARTIAL;
-   putback_lru_pages(>migratepages);
+   putback_movable_pages(>migratepages);
cc->nr_migratepages = 0;
goto out;
case ISOLATE_NONE:
@@ -1018,9 +1018,9 @@ static int compact_zone(struct zone *zone, struct 
compact_control *cc)
trace_mm_compaction_migratepages(nr_migrate - nr_remaining,
nr_remaining);
 
-   /* Release LRU pages not migrated */
+   /* Release isolated pages not migrated */
if (err) {
-   putback_lru_pages(>migratepages);
+   putback_movable_pages(>migratepages);
cc->nr_migratepages = 0;
if (err == -ENOMEM) {
ret = COMPACT_PARTIAL;
diff --git a/mm/migrate.c b/mm/migrate.c
index a771751..107a281 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -80,6 +80,26 @@ void putback_lru_pages(struct list_head *l)
list_del(>lru);
dec_zone_page_state(page, NR_ISOLATED_ANON +
page_is_file_cache(page));
+   putback_lru_page(page);
+   }
+}
+
+/*
+ * Put previously isolated pages back onto the appropriate lists
+ * from where they were once taken off for compaction/migration.
+ *
+ * This function shall be used instead of putback_lru_pages(),
+ * whenever the isolated pageset has been built by isolate_migratepages_range()
+ */
+void putback_movable_pages(struct list_head *l)
+{
+   struct page *page;
+   struct page *page2;
+
+   list_for_each_entry_safe(page, page2, l, lru) {
+   list_del(>lru);
+   dec_zone_page_state(page, NR_ISOLATED_ANON +
+   page_is_file_cache(page));
if (unlikely(balloon_page_movable(page)))
balloon_page_putback(page);
else
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 8fd1919..6b990cb 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5795,7 +5795,7 @@ static int __alloc_contig_migrate_range(struct 
compact_control *cc,
0, false, MIGRATE_SYNC);
}
 
-   putback_lru_pages(>migratepages);
+   putback_movable_pages(>migratepages);
return ret > 0 ? 0 : ret;
 }
 
-- 
1.7.11.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 v12 2/7] mm: redefine address_space.assoc_mapping

[Rafael Aquini]

This patch overhauls struct address_space.assoc_mapping renaming it to
address_space.private_data and its type is redefined to void*.
By this approach we consistently name the .private_* elements from
struct address_space as well as allow extended usage for address_space
association with other data structures through ->private_data.

Also, all users of old ->assoc_mapping element are converted to reflect
its new name and type change (->private_data).

Signed-off-by: Rafael Aquini 
---
 fs/buffer.c| 12 ++--
 fs/gfs2/glock.c|  2 +-
 fs/inode.c |  2 +-
 fs/nilfs2/page.c   |  2 +-
 include/linux/fs.h |  2 +-
 5 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/fs/buffer.c b/fs/buffer.c
index b5f0442..e0bad95 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -555,7 +555,7 @@ void emergency_thaw_all(void)
  */
 int sync_mapping_buffers(struct address_space *mapping)
 {
-   struct address_space *buffer_mapping = mapping->assoc_mapping;
+   struct address_space *buffer_mapping = mapping->private_data;
 
if (buffer_mapping == NULL || list_empty(>private_list))
return 0;
@@ -588,10 +588,10 @@ void mark_buffer_dirty_inode(struct buffer_head *bh, 
struct inode *inode)
struct address_space *buffer_mapping = bh->b_page->mapping;
 
mark_buffer_dirty(bh);
-   if (!mapping->assoc_mapping) {
-   mapping->assoc_mapping = buffer_mapping;
+   if (!mapping->private_data) {
+   mapping->private_data = buffer_mapping;
} else {
-   BUG_ON(mapping->assoc_mapping != buffer_mapping);
+   BUG_ON(mapping->private_data != buffer_mapping);
}
if (!bh->b_assoc_map) {
spin_lock(_mapping->private_lock);
@@ -788,7 +788,7 @@ void invalidate_inode_buffers(struct inode *inode)
if (inode_has_buffers(inode)) {
struct address_space *mapping = >i_data;
struct list_head *list = >private_list;
-   struct address_space *buffer_mapping = mapping->assoc_mapping;
+   struct address_space *buffer_mapping = mapping->private_data;
 
spin_lock(_mapping->private_lock);
while (!list_empty(list))
@@ -811,7 +811,7 @@ int remove_inode_buffers(struct inode *inode)
if (inode_has_buffers(inode)) {
struct address_space *mapping = >i_data;
struct list_head *list = >private_list;
-   struct address_space *buffer_mapping = mapping->assoc_mapping;
+   struct address_space *buffer_mapping = mapping->private_data;
 
spin_lock(_mapping->private_lock);
while (!list_empty(list)) {
diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
index 6114571..904a808 100644
--- a/fs/gfs2/glock.c
+++ b/fs/gfs2/glock.c
@@ -766,7 +766,7 @@ int gfs2_glock_get(struct gfs2_sbd *sdp, u64 number,
mapping->host = s->s_bdev->bd_inode;
mapping->flags = 0;
mapping_set_gfp_mask(mapping, GFP_NOFS);
-   mapping->assoc_mapping = NULL;
+   mapping->private_data = NULL;
mapping->backing_dev_info = s->s_bdi;
mapping->writeback_index = 0;
}
diff --git a/fs/inode.c b/fs/inode.c
index b03c719..4cac8e1 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -165,7 +165,7 @@ int inode_init_always(struct super_block *sb, struct inode 
*inode)
mapping->host = inode;
mapping->flags = 0;
mapping_set_gfp_mask(mapping, GFP_HIGHUSER_MOVABLE);
-   mapping->assoc_mapping = NULL;
+   mapping->private_data = NULL;
mapping->backing_dev_info = _backing_dev_info;
mapping->writeback_index = 0;
 
diff --git a/fs/nilfs2/page.c b/fs/nilfs2/page.c
index 3e7b2a0..07f76db 100644
--- a/fs/nilfs2/page.c
+++ b/fs/nilfs2/page.c
@@ -431,7 +431,7 @@ void nilfs_mapping_init(struct address_space *mapping, 
struct inode *inode,
mapping->host = inode;
mapping->flags = 0;
mapping_set_gfp_mask(mapping, GFP_NOFS);
-   mapping->assoc_mapping = NULL;
+   mapping->private_data = NULL;
mapping->backing_dev_info = bdi;
mapping->a_ops = _aops;
 }
diff --git a/include/linux/fs.h b/include/linux/fs.h
index b33cfc9..0982565 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -418,7 +418,7 @@ struct address_space {
struct backing_dev_info *backing_dev_info; /* device readahead, etc */
spinlock_t  private_lock;   /* for use by the address_space 
*/
struct list_headprivate_list;   /* ditto */
-   struct address_space*assoc_mapping; /* ditto */
+   void*private_data;  /* ditto */
 } __attribute__((aligned(sizeof(long;
/*
 * On most architectures that alignment is already the case; but
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to