Re: [PATCH] sched: Fix new task's load avg removed from source CPU in

[kbuild test robot]

Hi Yuyang,

[auto build test WARNING on tip/sched/core]
[also build test WARNING on v4.4-rc5 next-20151216]

url:
https://github.com/0day-ci/linux/commits/Yuyang-Du/sched-Fix-new-task-s-load-avg-removed-from-source-CPU-in/20151216-154529
config: i386-randconfig-x000-12141102 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   kernel/sched/fair.c: In function 'remove_entity_load_avg':
>> kernel/sched/fair.c:2919:2: warning: ISO C90 forbids mixed declarations and 
>> code [-Wdeclaration-after-statement]
 u64 last_update_time_copy;
 ^

vim +2919 kernel/sched/fair.c

9ee474f5 Paul Turner 2012-10-04  2903  /*
9d89c257 Yuyang Du   2015-07-15  2904   * Task first catches up with cfs_rq, 
and then subtract
9d89c257 Yuyang Du   2015-07-15  2905   * itself from the cfs_rq (task must be 
off the queue now).
9ee474f5 Paul Turner 2012-10-04  2906   */
9d89c257 Yuyang Du   2015-07-15  2907  void remove_entity_load_avg(struct 
sched_entity *se)
2dac754e Paul Turner 2012-10-04  2908  {
9d89c257 Yuyang Du   2015-07-15  2909   struct cfs_rq *cfs_rq = cfs_rq_of(se);
9d89c257 Yuyang Du   2015-07-15  2910   u64 last_update_time;
9d89c257 Yuyang Du   2015-07-15  2911  
a13869ac Yuyang Du   2015-12-16  2912   /*
a13869ac Yuyang Du   2015-12-16  2913* Newly created task should not be 
removed from the source CPU before migration
a13869ac Yuyang Du   2015-12-16  2914*/
a13869ac Yuyang Du   2015-12-16  2915   if (se->avg.last_update_time == 0)
a13869ac Yuyang Du   2015-12-16  2916   return;
a13869ac Yuyang Du   2015-12-16  2917  
9d89c257 Yuyang Du   2015-07-15  2918  #ifndef CONFIG_64BIT
9d89c257 Yuyang Du   2015-07-15 @2919   u64 last_update_time_copy;
9ee474f5 Paul Turner 2012-10-04  2920  
9d89c257 Yuyang Du   2015-07-15  2921   do {
9d89c257 Yuyang Du   2015-07-15  2922   last_update_time_copy = 
cfs_rq->load_last_update_time_copy;
9d89c257 Yuyang Du   2015-07-15  2923   smp_rmb();
9d89c257 Yuyang Du   2015-07-15  2924   last_update_time = 
cfs_rq->avg.last_update_time;
9d89c257 Yuyang Du   2015-07-15  2925   } while (last_update_time != 
last_update_time_copy);
9d89c257 Yuyang Du   2015-07-15  2926  #else
9d89c257 Yuyang Du   2015-07-15  2927   last_update_time = 
cfs_rq->avg.last_update_time;

:: The code at line 2919 was first introduced by commit
:: 9d89c257dfb9c51a532d69397f6eed75e5168c35 sched/fair: Rewrite runnable 
load and utilization average tracking

:: TO: Yuyang Du 
:: CC: Ingo Molnar 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH v3 4/4] clk: bcm2835: Add PWM clock support to the device tree

[Remi Pommarel]

On Mon, Dec 07, 2015 at 08:09:47PM -0800, Eric Anholt wrote:
> Stefan Wahren  writes:
> 
> > Hi Remi,
> >
> > Am 07.12.2015 um 19:17 schrieb Remi Pommarel:
> >> Hi Stefan,
> >>
> >> On Sun, Dec 06, 2015 at 10:16:25PM +0100, Stefan Wahren wrote:
> >>> Hi Remi,
> >>>
> >>> please send this patch to devicet...@vger.kernel.org.
> >>
> >> Ok, just to be sure I understand the process here. I should resend a new
> >> version of the whole patchset including the devicetree mailing list as
> >> recipent. Then the first 3 patches will eventually get pushed by a clock
> >> subsystem maintainer. And finally this last patch will be pushed by a
> >> devicetree maintainer.
> >>
> >> Am I right here ?
> >
> > sorry for the confusion. I mean that you send a copy to 
> > devicet...@vger.kernel.org so subscribers have a chance to review.
> >
> > I'm not sure but according to your subject you suggest that this dts 
> > patch should go through clock subsystem which isn't optimal. This should 
> > be better applied by Stephen or Eric.
> 
> It would be applied by me, but that's for me to worry about, not the
> patch submitter.  The subject prefix would be "ARM: bcm2835: ", but
> that's trivial for me to fix when applying, not the kind of thing worth
> asking for a respin for.

Thanks for review.

I'll submit dt patch to devicet...@vger.kernel.org for review. Is it better
to submit the whole patchset (patch 1 to 4) to provide some context for the
device tree patch or just this patch alone ?

Best Regards,

-- 
Remi
--
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 10/14] perf tools: Enable indices setting syntax for BPF maps

[Jiri Olsa]

On Wed, Dec 16, 2015 at 10:02:28AM +0800, Wangnan (F) wrote:
> 
> 
> On 2015/12/15 21:42, Jiri Olsa wrote:
> >On Mon, Dec 14, 2015 at 10:39:19AM +, Wang Nan wrote:
> >>This patch introduce a new syntax to perf event parser:
> >>
> >>  # perf record -e 
> >> './test_bpf_map_3.c/maps:channel.value[0,1,2,3...5]=101/' usleep 2
> >why 3 dots? I'd think the standard is 2 ?
> 
> The standard (actually it is a gcc extension, not C standard) is 3 dots.
> Please have a look at [1] and [2]. Although I also think '..' is better.
> 
> So after you seeing this, do you still think we should follow our
> intuition instead of following GCC? If you still prefer '..' I'll
> change it.

I'm ok with '...'

I think I only thought about '..' as a standard because of the way I use git 
log ;-)

thanks,
jirka

> 
> Thank you.
> 
> [1] https://lkml.org/lkml/2015/11/23/4
> [2] https://gcc.gnu.org/onlinedocs/gcc/Case-Ranges.html
> 
> Thank you.
> 
> >just curious
> >   [0,1,2,3..5]
> >3 made me think there's something speecial about it ;-)
> >
> >
> >jirka
> 
> 
--
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 08/11] KVM: MMU: use page track for non-leaf shadow pages

[Kai Huang]

On 12/15/2015 05:10 PM, Xiao Guangrong wrote:



On 12/15/2015 03:52 PM, Kai Huang wrote:


  static bool __mmu_gfn_lpage_is_disallowed(gfn_t gfn, int level,
@@ -2140,12 +2150,18 @@ static struct kvm_mmu_page 
*kvm_mmu_get_page(struct kvm_vcpu *vcpu,

  hlist_add_head(>hash_link,
>kvm->arch.mmu_page_hash[kvm_page_table_hashfn(gfn)]);
  if (!direct) {
-if (rmap_write_protect(vcpu, gfn))
+/*
+ * we should do write protection before syncing pages
+ * otherwise the content of the synced shadow page may
+ * be inconsistent with guest page table.
+ */
+account_shadowed(vcpu->kvm, sp);
+
+if (level == PT_PAGE_TABLE_LEVEL &&
+  rmap_write_protect(vcpu, gfn))
  kvm_flush_remote_tlbs(vcpu->kvm);
I think your modification is good but I am little bit confused here. 
In account_shadowed, if
sp->role.level > PT_PAGE_TABLE_LEVEL, the sp->gfn is write protected, 
and this is reasonable. So why

write protecting the gfn of PT_PAGE_TABLE_LEVEL here?


Because the shadow page will become 'sync' that means the shadow page 
will be synced
with the page table in guest. So the shadow page need to be 
write-protected to avoid

the guest page table is changed when we do the 'sync' thing.

The shadow page need to be write-protected to avoid that guest page 
table is changed
when we are syncing the shadow page table. See kvm_sync_pages() after 
doing

rmap_write_protect().
I see. So why are you treat PT_PAGE_TABLE_LEVEL gfn separately here? why 
this cannot be done in account_shadowed, as you did for upper level sp? 
Actually I am thinking whether account_shadowed is overdoing things. 
From it's name it should only *account* shadow sp, but now it also does 
write protection and disable large page mapping.


Thanks,
-Kai



  /*
   * remove the guest page from the tracking pool which stops the 
interception
   * of corresponding access on that page. It is the opposed 
operation of
@@ -134,20 +160,12 @@ void kvm_page_track_remove_page(struct kvm 
*kvm, gfn_t gfn,

  struct kvm_memory_slot *slot;
  int i;
-WARN_ON(!check_mode(mode));
-
  for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++) {
  slots = __kvm_memslots(kvm, i);
  slot = __gfn_to_memslot(slots, gfn);
  spin_lock(>mmu_lock);
-update_gfn_track(slot, gfn, mode, -1);
-
-/*
- * allow large page mapping for the tracked page
- * after the tracker is gone.
- */
-kvm_mmu_gfn_allow_lpage(slot, gfn);
+kvm_slot_page_track_remove_page_nolock(kvm, slot, gfn, mode);

Looks you need to merge this part with patch 1, as you are modifying
kvm_page_track_{add,remove}_page here, which are introduced in your 
patch 1.


Indeed, it is better.




--
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: 4.3 kernel panics when MMC/SDHC card is inserted on thinkpad

[Adrian Hunter]

On 15/12/15 18:01, Ulf Hansson wrote:
> +Adrian
> 
> On 8 November 2015 at 23:05, Denis Bychkov  wrote:
>> The only started in 4.3 kernel (at least RC-5), 4.2.x does not have
>> this problem. The kernel panic happens immediately after the SDHC card
>> is inserted, reproducibility is 100%. If the system boots up with the
>> card already inserted, it will crash as soon as sdhci_pci module is
>> loaded. If the module is unloaded/blacklisted, obviously, nothing
>> happens as the system does not see the MMC card reader.
>> The machine is Lenovo thinkpad T-510 laptop with Intel Westmere
>> CPU/3400 series chipset running 64-bit kernel 4.3.0.
>>
>> (somewhat) relevant kernel configuration bits:
>> # CONFIG_CALGARY_IOMMU is not set
>> CONFIG_IOMMU_HELPER=y
>> CONFIG_VFIO_IOMMU_TYPE1=m
>> CONFIG_IOMMU_API=y
>> CONFIG_IOMMU_SUPPORT=y
>> # Generic IOMMU Pagetable Support
>> CONFIG_IOMMU_IOVA=y
>> # CONFIG_AMD_IOMMU is not set
>> CONFIG_INTEL_IOMMU=y
>> CONFIG_INTEL_IOMMU_DEFAULT_ON=y
>> CONFIG_INTEL_IOMMU_FLOPPY_WA=y
>> # CONFIG_IOMMU_STRESS is not set
>> CONFIG_KVM_INTEL=m
>> CONFIG_PCI_MMCONFIG=y
>> # Supported MMC/SDIO adapters
>> CONFIG_MMC=m
>> # CONFIG_MMC_DEBUG is not set
>> # CONFIG_MMC_CLKGATE is not set
>> # MMC/SD/SDIO Card Drivers
>> CONFIG_MMC_BLOCK=m
>> CONFIG_MMC_BLOCK_MINORS=8
>> CONFIG_MMC_BLOCK_BOUNCE=y
>> CONFIG_MMC_TEST=m
>> # MMC/SD/SDIO Host Controller Drivers
>> CONFIG_MMC_SDHCI=m
>> CONFIG_MMC_SDHCI_PCI=m
>> CONFIG_MMC_RICOH_MMC=y
>> CONFIG_MMC_SDHCI_ACPI=m
>>
>> Card reader device:
>> 0d:00.0 SD Host controller: Ricoh Co Ltd MMC/SD Host Controller (rev 01)
>> Subsystem: Lenovo MMC/SD Host Controller
>> Flags: bus master, fast devsel, latency 0, IRQ 16
>> Memory at f210 (32-bit, non-prefetchable) [size=256]
>> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
>> Capabilities: [78] Power Management version 3
>> Capabilities: [80] Express Endpoint, MSI 00
>> Capabilities: [100] Virtual Channel
>> Capabilities: [800] Advanced Error Reporting
>> Kernel driver in use: sdhci-pci
>> Kernel modules: sdhci_pci
>>
>> The panic report caught via netconsole:
>>
>> [22946.904308] [ cut here ]
>> [22946.906564] kernel BUG at drivers/iommu/intel-iommu.c:3485!
>> [22946.908801] invalid opcode:  [#1] PREEMPT SMP
>> [22946.93] Modules linked in: netconsole dm_mod bnep
>> cpufreq_powersave cpufreq_stats cpufreq_conservative cpufreq_userspace
>> coretemp intel_powerclamp kvm_intel kvm crct10dif_pclmul crc32_pclmul
>> jitterentropy_rng hmac sha256_ssse3 sha256_generic drbg
>> snd_hda_codec_hdmi ansi_cprng gpio_ich iTCO_wdt iTCO_vendor_support
>> aesni_intel arc4 aes_x86_64 nouveau mxm_wmi lrw gf128mul glue_helper
>> ablk_helper iwldvm cryptd psmouse mac80211 uvcvideo serio_raw pcspkr
>> nd_e820 videobuf2_vmalloc ttm evdev videobuf2_memops i2c_algo_bit
>> mousedev btusb videobuf2_core btrtl drm_kms_helper v4l2_common mac_hid
>> btbcm videodev btintel drm snd_hda_codec_conexant bluetooth
>> snd_hda_codec_generic iwlwifi syscopyarea sysfillrect sysimgblt
>> fb_sys_fops snd_hda_intel snd_hda_codec cfg80211 snd_hda_core
>> snd_hwdep i2c_i801 thinkpad_acpi lpc_ich snd_pcm sg mfd_core nvram
>> i2c_core snd_timer intel_ips rfkill hwmon snd mei_me soundcore
>> intel_agp mei tpm_tis intel_gtt shpchp tpm agpgart battery rtc_cmos ac
>> video thermal wmi acpi_cpufreq button processor tp_smapi(O)
>> thinkpad_ec(O) autofs4 ext4 crc16 mbcache jbd2 btrfs xor hid_generic
>> usbhid hid raid6_pq sr_mod cdrom sd_mod uas usb_storage firewire_ohci
>> ahci libahci crc32c_intel libata atkbd sdhci_pci scsi_mod ehci_pci
>> sdhci ehci_hcd e1000e firewire_core mmc_core crc_itu_t ptp usbcore
>> usb_common pps_core
>> [22946.929431] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G   O
>> 4.3.0-westmere #1
>> [22946.932551] Hardware name: LENOVO 4313CTO/4313CTO, BIOS 6MET92WW
>> (1.52 ) 09/26/2012
>> [22946.935701] task: 88023231a580 ti: 88023232c000 task.ti:
>> 88023232c000
>> [22946.938878] RIP: 0010:[]  []
>> intel_unmap+0x1d0/0x210
>> [22946.942117] RSP: 0018:88023bd83da8  EFLAGS: 00010046
>> [22946.945341] RAX:  RBX: 880231ea5580 RCX: 
>> 0002
>> [22946.948592] RDX:  RSI: fffebda0 RDI: 
>> 880231e7d098
>> [22946.951855] RBP: 88023bd83de0 R08:  R09: 
>> 
>> [22946.955131] R10: 563f08fc R11: 1849050d R12: 
>> 880231e7d098
>> [22946.958423] R13: 8800bacbbc20 R14: fffebda0 R15: 
>> 
>> [22946.961723] FS:  () GS:88023bd8()
>> knlGS:
>> [22946.965051] CS:  0010 DS:  ES:  CR0: 8005003b
>> [22946.968387] CR2: e4d9c0e0 CR3: 01a0c000 CR4: 
>> 06e0
>> [22946.971760] Stack:
>> [22946.975131]  8800bacbbc60  880231ea5580
>> 880231ea5580
>> [22946.978598]  

Re: [PATCH] clocksource/drivers/pistachio: Fix wrong calculated clocksource read value

[Jisheng Zhang]

On Wed, 16 Dec 2015 15:36:09 +0800 Jisheng Zhang wrote:

> On Wed, 16 Dec 2015 15:28:07 +0800 wrote:
> 
> > On Wed, 16 Dec 2015 15:11:25 +0800
> > Jisheng Zhang  wrote:
> >   
> > > Dear Daniel,
> > > 
> > > On Tue, 15 Dec 2015 21:59:30 +0100 Daniel Lezcano wrote:
> > > 
> > > > On 11/25/2015 04:42 PM, Jisheng Zhang wrote:  
> > > > > Let's assume the counter value is 0xf00, the pistachio 
> > > > > clocksource
> > 
> > oops, sorry, should be 0xf000. Do I need to send a v2 patch?  
> 
> And in fact, clocksource_mmio_readw_down() also has similar issue, but it 
> masks

oops, sorry, I really need a cup of coffee. I mean clocksource_mmio_readl_down()

> with c->mask before return, the c->mask is less than 32 bit (because the
> clocksource_mmio_init think number of valid bits > 32 or < 16 is invalid.)
> the higher 32 bits are masked off, so we never saw such issue. But we'd better
> to fix that, what's your opinion?
> 
> Thank you very much,
> Jisheng
> 
> >   
> > > > > read cycles function would return 0x0fff, but it should
> > > > > return 0xfff.
> > > > >
> > > > > We fix this issue by calculating bitwise-not counter, then cast to
> > > > > cycle_t.
> > > > >
> > > > > Signed-off-by: Jisheng Zhang 
> > > > 
> > > > Hi Jisheng,
> > > > 
> > > > I tried to reproduce this behavior on x86_64 but without success.
> > > > 
> > > > On which architecture did you produce this result ? Do you have a 
> > > > simple 
> > > > test program to check with ?  
> > > 
> > > I have no HW platforms with pistachio, just read the code and run the
> > > following test code in x86_64 and x86_32:
> > > 
> > > #include 
> > > unsigned long long pistachio_clocksource_read_cycles()
> > > {
> > >   unsigned int counter = 0xf00;
> > 
> > should be unsigned int counter = 0xf000;
> >   
> > >   return ~(unsigned long long)counter;
> > > }
> > > int main()
> > > {
> > >   printf("%llx\n", pistachio_clocksource_read_cycles());
> > >   return 0;
> > > }
> > > 
> > > Thanks,
> > > Jisheng
> > > 
> > > ___
> > > linux-arm-kernel mailing list
> > > linux-arm-ker...@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >   
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
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 v5 0/8] Additional kmsg devices

[Richard Weinberger]

Am 16.12.2015 um 00:46 schrieb Joe Perches:
> On Tue, 2015-10-27 at 11:28 +0100, Paul Osmialowski wrote:
>> Dear All,
>>
>> This is the fifth iteration of Marcin Niesluchowski's serie of patches
>> extending kmsg interface with ability to dynamically create (and destroy)
>> kmsg-like devices which can be used by userspace for logging.
>>
>> This iteration introduces two changes:
>>
>> 1. selftests are rearranged to use kselftest.h API
>>
>> 2. A disputed  patch "add predefined _PID, _TID, _COMM keywords to kmsg*
>>log dict" is removed - no chance it will be ever accepted. It is not
>>critical for this patchset as a whole.
>>
>> Best regards,
>> Paul
>>
>> Marcin Niesluchowski (6):
>>   printk: add one function for storing log in proper format
>>   kmsg: introduce additional kmsg devices support
>>   kmsg: add additional buffers support to memory class
>>   kmsg: add function for adding and deleting additional buffers
>>   kmsg: add ioctl for adding and deleting kmsg* devices
>>   kmsg: add ioctl for kmsg* devices operating on buffers
>>
>> Paul Osmialowski (2):
>>   printk: extract kmsg-related routines from printk.c to kmsg.c
>>   kmsg: selftests
>>
> 
> Andrew?  Are you or anyone else interested in picking up this patchset?

I know I'm repeating myself. But this should be done in userspace.

Thanks,
//richard
--
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: PELT initial task load and wake_up_new_task()

[Yuyang Du]

On Tue, Dec 15, 2015 at 10:45:53AM -0800, Steve Muckle wrote:
> On 12/14/2015 06:24 PM, Yuyang Du wrote:
> >>> On Fri, Dec 11, 2015 at 06:01:45PM -0800, Steve Muckle wrote:
>  In init_entity_runnable_average() the last_update_time is initialized to
>  zero. The task is given max load and utilization as a pessimistic
>  initial estimate.
> 
>  But if in wake_up_new_task() the task is placed on a CPU other than
>  where it was created, __update_load_avg() will be called via
>  set_task_cpu() -> migrate_task_rq_fair() -> remove_entity_load_avg().
> 
>  Since last_update_time is zero the delta will be huge and the task's
>  load will be entirely decayed away before it is enqueued at the
>  destination CPU.
> >>>  
> >>> Since the new task's last_update_time is equal to 0, it will not be 
> >>> decayed.
> >>
> >> Can you point me to the code for that logic? I don't see anything that
> >> prevents the decay when a newly woken task is placed on a different CPU
> >> via the call chain I mentioned above. My testing also shows the load
> >> being decayed to zero.
> >>
> > You may search the last_update_time, and see it would be treated differently
> > if it is 0. Hope this may be helpful.
> 
> Are you referring to the test in enqueue_entity_load_avg()? If so that
> isn't called until after remove_entity_load_avg() in this scenario,
> which has no check on last_update_time.
 
Indeed it is. Sorry that I did not look at this carefully before.

I think it should still be regarded as migration. It looks better as such.

Hope the following patch should work.

---
Subject: [PATCH] sched: Fix new task's load avg removed from source CPU in
 wake_up_new_task()

If a newly created task is selected to go to a different CPU in fork
balance when it wakes up the first time, its load averages should
not be removed from the source CPU since they are never added to
it before.

Fix it in remove_entity_load_avg(): when entity's last_update_time
is 0, simply return. This should precisely identify the case in
question, because in normal migration, the last_update_time is
set to 0 after remove_entity_load_avg().

Reported-by: Steve Muckle 
Signed-off-by: Yuyang Du 
---
 kernel/sched/fair.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index e3266eb..4676988 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2909,6 +2909,12 @@ void remove_entity_load_avg(struct sched_entity *se)
struct cfs_rq *cfs_rq = cfs_rq_of(se);
u64 last_update_time;
 
+   /*
+* Newly created task should not be removed from the source CPU before 
migration
+*/
+   if (se->avg.last_update_time == 0)
+   return;
+
 #ifndef CONFIG_64BIT
u64 last_update_time_copy;
 
-- 
--
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] clocksource/drivers/pistachio: Fix wrong calculated clocksource read value

[Jisheng Zhang]

On Wed, 16 Dec 2015 15:28:07 +0800 wrote:

> On Wed, 16 Dec 2015 15:11:25 +0800
> Jisheng Zhang  wrote:
> 
> > Dear Daniel,
> > 
> > On Tue, 15 Dec 2015 21:59:30 +0100 Daniel Lezcano wrote:
> >   
> > > On 11/25/2015 04:42 PM, Jisheng Zhang wrote:
> > > > Let's assume the counter value is 0xf00, the pistachio clocksource  
> 
> oops, sorry, should be 0xf000. Do I need to send a v2 patch?

And in fact, clocksource_mmio_readw_down() also has similar issue, but it masks
with c->mask before return, the c->mask is less than 32 bit (because the
clocksource_mmio_init think number of valid bits > 32 or < 16 is invalid.)
the higher 32 bits are masked off, so we never saw such issue. But we'd better
to fix that, what's your opinion?

Thank you very much,
Jisheng

> 
> > > > read cycles function would return 0x0fff, but it should
> > > > return 0xfff.
> > > >
> > > > We fix this issue by calculating bitwise-not counter, then cast to
> > > > cycle_t.
> > > >
> > > > Signed-off-by: Jisheng Zhang   
> > > 
> > > Hi Jisheng,
> > > 
> > > I tried to reproduce this behavior on x86_64 but without success.
> > > 
> > > On which architecture did you produce this result ? Do you have a simple 
> > > test program to check with ?
> > 
> > I have no HW platforms with pistachio, just read the code and run the
> > following test code in x86_64 and x86_32:
> > 
> > #include 
> > unsigned long long pistachio_clocksource_read_cycles()
> > {
> > unsigned int counter = 0xf00;  
> 
> should be unsigned int counter = 0xf000;
> 
> > return ~(unsigned long long)counter;
> > }
> > int main()
> > {
> > printf("%llx\n", pistachio_clocksource_read_cycles());
> > return 0;
> > }
> > 
> > Thanks,
> > Jisheng
> > 
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel  
> 

--
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 04/11] KVM: page track: add the framework of guest page tracking

[Kai Huang]

On 12/15/2015 04:46 PM, Xiao Guangrong wrote:



On 12/15/2015 03:06 PM, Kai Huang wrote:

Hi Guangrong,

I am starting to review this series, and should have some comments or 
questions, you can determine

whether they are valuable :)


Thank you very much for your review and breaking the silent on this 
patchset. ;)




+static void page_track_slot_free(struct kvm_memory_slot *slot)
+{
+int i;
+
+for (i = 0; i < KVM_PAGE_TRACK_MAX; i++)
+if (slot->arch.gfn_track[i]) {
+kvfree(slot->arch.gfn_track[i]);
+slot->arch.gfn_track[i] = NULL;
+}
+}
+
+int kvm_page_track_create_memslot(struct kvm_memory_slot *slot,
+  unsigned long npages)
+{
+int  i, pages = gfn_to_index(slot->base_gfn + npages - 1,
+  slot->base_gfn, PT_PAGE_TABLE_LEVEL) + 1;
+
+for (i = 0; i < KVM_PAGE_TRACK_MAX; i++) {
+slot->arch.gfn_track[i] = kvm_kvzalloc(pages *
+sizeof(*slot->arch.gfn_track[i]));
+if (!slot->arch.gfn_track[i])
+goto track_free;
+}
+
+return 0;
+
+track_free:
+page_track_slot_free(slot);
+return -ENOMEM;
+}
Is it necessary to use the 'unsigned long npages' pareameter? In my 
understanding you are going to


The type, 'int', is used here as I followed the style of 'struct 
kvm_lpage_info'.


4 bytes should be enough to track all users and signed type is good to 
track

overflow.

track all GFNs in the memory slot anyway, right? If you want to keep 
npages, I think it's better to
add a base_gfn as well otherwise you are assuming you are going to 
track the npages GFN starting

from slot->base_gfn.


Yes, any page in the memslot may be tracked so that there is a index 
for every

page.




+
+void kvm_page_track_free_memslot(struct kvm_memory_slot *free,
+ struct kvm_memory_slot *dont)
+{
+if (!dont || free->arch.gfn_track != dont->arch.gfn_track)
+page_track_slot_free(free);
+}
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c04987e..ad4888a 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7838,6 +7838,8 @@ void kvm_arch_free_memslot(struct kvm *kvm, 
struct kvm_memory_slot *free,

  free->arch.lpage_info[i - 1] = NULL;
  }
  }
+
+kvm_page_track_free_memslot(free, dont);
  }
  int kvm_arch_create_memslot(struct kvm *kvm, struct 
kvm_memory_slot *slot,
@@ -7886,6 +7888,9 @@ int kvm_arch_create_memslot(struct kvm *kvm, 
struct kvm_memory_slot *slot,

  }
  }
+if (kvm_page_track_create_memslot(slot, npages))
+goto out_free;
+
Looks essentially you are allocating one int for all GFNs of the slot 
unconditionally. In my
understanding for most of memory slots, we are not going to track 
them, so isn't it going to be

wasteful of memory?



Yes, hmm... maybe we can make the index as "unsigned short" then 1G 
memory only needs 512k index

buffer. It is not so unacceptable.

Those comments are really minor and don't bother on this :)

Thanks,
-Kai

--
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 06/11] KVM: MMU: let page fault handler be aware tracked page

[Kai Huang]

On 12/15/2015 05:03 PM, Xiao Guangrong wrote:



On 12/15/2015 04:11 PM, Kai Huang wrote:



On 12/01/2015 02:26 AM, Xiao Guangrong wrote:

The page fault caused by write access on the write tracked page can not
be fixed, it always need to be emulated. page_fault_handle_page_track()
is the fast path we introduce here to skip holding mmu-lock and shadow
page table walking
Why can it be out side of mmu-lock? Is it OK that some other thread 
removes tracking of this page
simultaneously? Shall we assuming the emulation code should handle 
this case?




What your mentioned is the worst case, if that happen the vcpu will spend
longer time to emulate the access rather then retry it. It is bad but 
it is

the rare contention. It is worth speeding up the common / most case.
My concern is when this case happen, whether emulating the access is 
still the right behavior, you know, after other thread removed the GFN 
from tracking..
And as the notifier's  track_write call back will be called in the 
emulating code, won't there be problem if the GFN has been removed from 
tracking by other thread?


Thanks,
-Kai


Even it works for write protection, is it OK for other purpose 
tracking (as your tracking framework

can be extended for other purpose)?


We only need to make sure that no track event is lost, i.e, we can not
skip the case that the index is changed from 0 to 1.

If we see index is 0, the vcpu can hold the mmu-lock and go to slow path
anyway so no track event will be lost.



However, if the page table is not present, it is worth making the page
table entry present and readonly to make the read access happy
It's  fine for tracking write from guest. But what if I want to track 
every read from guest?

Probably I am exaggerating :)



Then we do not go to the real page fault handler, just keep the shadow
page entry non-present.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.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/

Re: [RFC/RFT PATCH] watchdog: Move watchdog device creation to watchdog_dev.c

[Wim Van Sebroeck]

Hi Pratyush,

> On 15/12/2015:06:56:50 PM, Guenter Roeck wrote:
> > On 12/14/2015 12:44 PM, Wim Van Sebroeck wrote:
> > >On Sun, Dec 13, 2015 at 10:24:35PM -0800, Guenter Roeck wrote:
> > >
> > >>On 12/13/2015 02:02 PM, Damien Riegel wrote:
> > >>>On Mon, Dec 07, 2015 at 09:41:03PM +0100, Wim Van Sebroeck wrote:
> > Hi All,
> > 
> > >On 12/07/2015 08:15 AM, Damien Riegel wrote:
> > >>On Sun, Dec 06, 2015 at 11:51:41AM -0800, Guenter Roeck wrote:
> > >>>The watchdog character device s currently created in
> > >>>watchdog_dev.c, and the watchdog device in watchdog_core.c. This
> > >>>results in cross-dependencies, as the device creation needs to
> > >>>know the watchdog character device number.
> > >>>
> > >>>On top of that, the watchdog character device is created before
> > >>>the watchdog device is created. This can result in race conditions
> > >>>if the watchdog device node is accessed before the watchdog device
> > >>>has been created.
> > >>>
> > >>>To solve the problem, move watchdog device creation into
> > >>>watchdog_dev.c, and create the watchdog device prior to creating
> > >>>its device node. Also move device class creation into
> > >>>watchdog_dev.c, since this is now the only place where the
> > >>>watchdog class is needed.
> > >>>
> > >>>Inspired by an earlier patch set from Damien Riegel.
> > >>>
> > >>>Cc: Damien Riegel 
> > >>>Signed-off-by: Guenter Roeck  --- Hi Damien,
> > >>>
> > >>>I think this approach would be a bit better. The watchdog device
> > >>>isn't really used in the watchdog core code, so it is better
> > >>>created in watchdog_dev.c. That also fits well with other pending
> > >>>changes, such as sysfs attribute support, and my attempts to move
> > >>>the ref/unref functions completely into the watchdog core. As a
> > >>>side effect, it also cleans up the error path in
> > >>>__watchdog_register_device().
> > >>>
> > >>>What do you think ?
> > >>
> > >>Hi Guenter,
> > >>
> > >>Like the idea, but I don't really get the separation. For instance,
> > >>you move watchdog_class in watchdog_dev.c but you keep watchdog_ida
> > >>in watchdog_core.c whereas it is only used for device
> > >>creation/deletion.
> > >>
> > >The class is watchdog driver internal, and it is device related, so
> > >I think it made sense to move it to watchdog_dev.c. On top of that,
> > >it will be needed there if/when we introduce sysfs attributes.
> > >
> > >The watchdog id can be determined by obtaining an id using ida, or
> > >it can be provided through the watchdog alias. The operation to get
> > >it is not device related, and it is not straightforward to obtain
> > >it, so I thought it makes sense to keep the code in watchdog_core.c.
> > >
> > >Of course a lot of it is personal preference.
> > >
> > 
> > Let me go back to how I saw the design when I created the generic
> > watchdog framework: When using watchdog device drivers we need to be
> > able to support the /dev/watchdog system. I also foresaw that we
> > should have a sysfs interface and I saw the future for watchdog
> > devices that you should be able to choose between the 2 different
> > systems. You should be able to use only the /dev/watchdog interfacing,
> > but you should also be able to use both a sysfs interface and a
> > /dev/watchdog interface and it should even be possible to have only a
> > sysfs interface in certain embedded devices. So that's why I split the
> > watchdog framework over 3 files: core code, the /dev/watchdog
> > interfacing and the sysfs code. Since I want to have compiled code
> > small enough when choosing either /Dev/watchdog or sysfs or both this
> > sounded the most logical thing to do (Unless you have a single file
> > full of #ifdef-ery that becomes unreadable).
> > 
> > So I do not agree to have sysfs code in watchdog_dev.c . It belongs in
> > watchdog_sysfs.c imho. If someone has a better idea, I'll be glad to
> > listen to it and see what the benefits are. But I want a clean system
> > for excluding both /dev/ (current watchdog_dev.c) and/or sysfs
> > (watchdog_sysfs.c) in the future. Off-course the current behaviour is
> > to have the /dev/ interface and have the option to add sysfs
> > attributes.
> > >>>
> > >>>I agree that keeping sysfs code separate makes sense, as someone might
> > >>>want to not use it.
> > >>>
> > >>I am not really sure about that. I don't recall a similar concern with
> > >>any other subsystem.
> > >>
> > >>Anyway, sure, we can move the code to another file. Sure, we can add a
> > >>configuration option. That means we'll also need to make several functions
> > >>non-static, and possibly move some functions out of watchdog_dev.c
> > >>into yet another file. But we'll need some 

Re: [RFC/RFT PATCH] watchdog: Move watchdog device creation to watchdog_dev.c

[Wim Van Sebroeck]

Hi Guenter,

> On 12/14/2015 12:44 PM, Wim Van Sebroeck wrote:
> >On Sun, Dec 13, 2015 at 10:24:35PM -0800, Guenter Roeck wrote:
> >
> >>On 12/13/2015 02:02 PM, Damien Riegel wrote:
> >>>On Mon, Dec 07, 2015 at 09:41:03PM +0100, Wim Van Sebroeck wrote:
> Hi All,
> 
> >On 12/07/2015 08:15 AM, Damien Riegel wrote:
> >>On Sun, Dec 06, 2015 at 11:51:41AM -0800, Guenter Roeck wrote:
> >>>The watchdog character device s currently created in
> >>>watchdog_dev.c, and the watchdog device in watchdog_core.c. This
> >>>results in cross-dependencies, as the device creation needs to
> >>>know the watchdog character device number.
> >>>
> >>>On top of that, the watchdog character device is created before
> >>>the watchdog device is created. This can result in race conditions
> >>>if the watchdog device node is accessed before the watchdog device
> >>>has been created.
> >>>
> >>>To solve the problem, move watchdog device creation into
> >>>watchdog_dev.c, and create the watchdog device prior to creating
> >>>its device node. Also move device class creation into
> >>>watchdog_dev.c, since this is now the only place where the
> >>>watchdog class is needed.
> >>>
> >>>Inspired by an earlier patch set from Damien Riegel.
> >>>
> >>>Cc: Damien Riegel 
> >>>Signed-off-by: Guenter Roeck  --- Hi Damien,
> >>>
> >>>I think this approach would be a bit better. The watchdog device
> >>>isn't really used in the watchdog core code, so it is better
> >>>created in watchdog_dev.c. That also fits well with other pending
> >>>changes, such as sysfs attribute support, and my attempts to move
> >>>the ref/unref functions completely into the watchdog core. As a
> >>>side effect, it also cleans up the error path in
> >>>__watchdog_register_device().
> >>>
> >>>What do you think ?
> >>
> >>Hi Guenter,
> >>
> >>Like the idea, but I don't really get the separation. For instance,
> >>you move watchdog_class in watchdog_dev.c but you keep watchdog_ida
> >>in watchdog_core.c whereas it is only used for device
> >>creation/deletion.
> >>
> >The class is watchdog driver internal, and it is device related, so
> >I think it made sense to move it to watchdog_dev.c. On top of that,
> >it will be needed there if/when we introduce sysfs attributes.
> >
> >The watchdog id can be determined by obtaining an id using ida, or
> >it can be provided through the watchdog alias. The operation to get
> >it is not device related, and it is not straightforward to obtain
> >it, so I thought it makes sense to keep the code in watchdog_core.c.
> >
> >Of course a lot of it is personal preference.
> >
> 
> Let me go back to how I saw the design when I created the generic
> watchdog framework: When using watchdog device drivers we need to be
> able to support the /dev/watchdog system. I also foresaw that we
> should have a sysfs interface and I saw the future for watchdog
> devices that you should be able to choose between the 2 different
> systems. You should be able to use only the /dev/watchdog interfacing,
> but you should also be able to use both a sysfs interface and a
> /dev/watchdog interface and it should even be possible to have only a
> sysfs interface in certain embedded devices. So that's why I split the
> watchdog framework over 3 files: core code, the /dev/watchdog
> interfacing and the sysfs code. Since I want to have compiled code
> small enough when choosing either /Dev/watchdog or sysfs or both this
> sounded the most logical thing to do (Unless you have a single file
> full of #ifdef-ery that becomes unreadable).
> 
> So I do not agree to have sysfs code in watchdog_dev.c . It belongs in
> watchdog_sysfs.c imho. If someone has a better idea, I'll be glad to
> listen to it and see what the benefits are. But I want a clean system
> for excluding both /dev/ (current watchdog_dev.c) and/or sysfs
> (watchdog_sysfs.c) in the future. Off-course the current behaviour is
> to have the /dev/ interface and have the option to add sysfs
> attributes.
> >>>
> >>>I agree that keeping sysfs code separate makes sense, as someone might
> >>>want to not use it.
> >>>
> >>I am not really sure about that. I don't recall a similar concern with
> >>any other subsystem.
> >>
> >>Anyway, sure, we can move the code to another file. Sure, we can add a
> >>configuration option. That means we'll also need to make several functions
> >>non-static, and possibly move some functions out of watchdog_dev.c
> >>into yet another file. But we'll need some guidance for that and an idea
> >>what is going to be acceptable.
> >>
> >>>The question is: can we make the /dev/watchdog entries optional ? That
> >>>would break the compatibility, right? Imho, it would be saner to keep
> >>>only one way 

Re: [PATCH] clocksource/drivers/pistachio: Fix wrong calculated clocksource read value

[Jisheng Zhang]

On Wed, 16 Dec 2015 15:11:25 +0800
Jisheng Zhang  wrote:

> Dear Daniel,
> 
> On Tue, 15 Dec 2015 21:59:30 +0100 Daniel Lezcano wrote:
> 
> > On 11/25/2015 04:42 PM, Jisheng Zhang wrote:  
> > > Let's assume the counter value is 0xf00, the pistachio clocksource

oops, sorry, should be 0xf000. Do I need to send a v2 patch?

> > > read cycles function would return 0x0fff, but it should
> > > return 0xfff.
> > >
> > > We fix this issue by calculating bitwise-not counter, then cast to
> > > cycle_t.
> > >
> > > Signed-off-by: Jisheng Zhang 
> > 
> > Hi Jisheng,
> > 
> > I tried to reproduce this behavior on x86_64 but without success.
> > 
> > On which architecture did you produce this result ? Do you have a simple 
> > test program to check with ?  
> 
> I have no HW platforms with pistachio, just read the code and run the
> following test code in x86_64 and x86_32:
> 
> #include 
> unsigned long long pistachio_clocksource_read_cycles()
> {
>   unsigned int counter = 0xf00;

should be unsigned int counter = 0xf000;

>   return ~(unsigned long long)counter;
> }
> int main()
> {
>   printf("%llx\n", pistachio_clocksource_read_cycles());
>   return 0;
> }
> 
> Thanks,
> Jisheng
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
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] clocksource/drivers/pistachio: Fix wrong calculated clocksource read value

[Jisheng Zhang]

Dear Daniel,

On Tue, 15 Dec 2015 21:59:30 +0100 Daniel Lezcano wrote:

> On 11/25/2015 04:42 PM, Jisheng Zhang wrote:
> > Let's assume the counter value is 0xf00, the pistachio clocksource
> > read cycles function would return 0x0fff, but it should
> > return 0xfff.
> >
> > We fix this issue by calculating bitwise-not counter, then cast to
> > cycle_t.
> >
> > Signed-off-by: Jisheng Zhang   
> 
> Hi Jisheng,
> 
> I tried to reproduce this behavior on x86_64 but without success.
> 
> On which architecture did you produce this result ? Do you have a simple 
> test program to check with ?

I have no HW platforms with pistachio, just read the code and run the
following test code in x86_64 and x86_32:

#include 
unsigned long long pistachio_clocksource_read_cycles()
{
unsigned int counter = 0xf00;
return ~(unsigned long long)counter;
}
int main()
{
printf("%llx\n", pistachio_clocksource_read_cycles());
return 0;
}

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

Re: [PATCH 5/6] bpf: hash: avoid to call kmalloc() in eBPF prog

[Ming Lei]

On Wed, Dec 16, 2015 at 7:10 AM, Alexei Starovoitov
 wrote:
> On Tue, Dec 15, 2015 at 07:21:03PM +0800, Ming Lei wrote:
>> kmalloc() is often a bit time-consuming, also
>> one atomic counter has to be used to track the total
>> allocated elements, which is also not good.
>>
>> This patch pre-allocates element pool in htab_map_alloc(),
>> then use percpu_ida to allocate one slot from the pool,
>> then the runtime allocation/freeing cost can be decreased.
>>
>> From my test, at least 10% fio throughput is improved in block
>> I/O test when tools/biolatency of bcc(iovisor) is running.
>>
>> Signed-off-by: Ming Lei 
>
> Looks very intersting as well.
> Approach looks good.
> If you can make a common allocation helper for this map and
> for blk-mq would be even better.

OK, I will see if it is doable.

>
>> - htab->elem_size = sizeof(struct htab_elem) +
>> -   round_up(htab->map.key_size, 8) +
>> -   htab->map.value_size;
>> + htab->elem_size = round_up(sizeof(struct htab_elem) +
>> +round_up(htab->map.key_size, 8) +
>> +htab->map.value_size,
>> +cache_line_size());
>
> this rounding to cache line is great for performance, but it's extra
> memory upfront which may not be needed. The per-allocation is a classic
> performance vs memory trade-off. In other cases it may hurt.

The current kmalloc allocation for 'struct htab_elem' is still cache line
aligned, that is one reason why I choose to do it, but we can change
it too.

> So could you change the patch to do pre-allocation only when
> requested by user space via extra flag for hash map or via
> new BPF_MAP_TYPE_HASH_PREALLOC type? Not sure yet whether flag or
> new type is better. I guess implementation will dictate.

Looks a better idea, then we can let user make the choice.

>
> PS
> Glad that you found iovisor/tools/biolatency useful.
> It's indeed pretty helpful to analyze real-time block io latency.

This tool is great and I have played it for a while, :-)



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

v4.4-rc1: /dev/console open fails with -EIO

[Junichi Nomura]

Since kernel v4.4-rc1, kdump capture service with Fedora23 / RHEL7.2
almost always fails on my test system which uses serial console. It
used to work fine until kernel v4.3.

Kdump fails with an error like this:
  kdump.sh[1040]: /bin/kdump.sh: line 8: /dev/console: Input/output error

The line 8 of kdump.sh is doing this:
  exec &> /dev/console
(http://pkgs.fedoraproject.org/cgit/kexec-tools.git/tree/dracut-kdump.sh)

and the EIO is returned by this code in tty_reopen():
if (!tty->count)
return -EIO;

Bisection tells that commit 79c1faa4511e ("tty: Remove
tty_wait_until_sent_from_close()") is the first bad commit.
Actually, after reverting the commit, kdump capture starts working
again.

Open of /dev/console used to return -EIO when it races with close.
(https://bugs.launchpad.net/ubuntu/+source/linux/+bug/554172/comments/245)
But the commit seems widening the race window.

  Before the commit:
tty_release()
  tty_lock(tty)
  tty->ops->close(tty, filp)
tty_unlock(tty)
tty_wait_until_sent()
// the window starts from here
tty_lock(tty)
  decrement tty->count
  tty_unlock(tty)
  (releasing tty if count became zero)

  After the commit
tty_release()
  // the window starts from here
  tty_lock(tty)
  tty->ops->close(tty, filp)
tty_wait_until_sent()
  decrement tty->count
  tty_unlock(tty)
  (releasing tty if count became zero)

While it might be possible for user space to cope with the problem
by retrying open(), there is no clue whether and how long it should.
Also current situation makes shell scripting like the above kdump.sh
fragile for this sort of timing change.

How about retrying tty_open in kernel instead, like the attached patch?
If !tty->count in tty_reopen() means the race has happened, that
seems reasonable.

---
Jun'ichi Nomura, NEC Corporation

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index bcc8e1e..070ea66 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -1462,8 +1462,9 @@ static int tty_reopen(struct tty_struct *tty)
 {
struct tty_driver *driver = tty->driver;
 
+   /* We cannot re-open tty which is being released. */
if (!tty->count)
-   return -EIO;
+   return -ERESTARTSYS;
 
if (driver->type == TTY_DRIVER_TYPE_PTY &&
driver->subtype == PTY_TYPE_MASTER)
@@ -2087,6 +2088,11 @@ retry_open:
 
if (IS_ERR(tty)) {
retval = PTR_ERR(tty);
+   if (retval == -ERESTARTSYS && !signal_pending(current)) {
+   tty_free_file(filp);
+   schedule();
+   goto retry_open;
+   }
goto err_file;
}
 --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] bpf: hash: convert per-hashtable lock into per-bucket bit spinlock

[Ming Lei]

On Wed, Dec 16, 2015 at 1:01 PM, Yang Shi  wrote:

>
> I recalled Steven confirmed raw_spin_lock has the lockdep benefit too in the
> patch review for changing to raw lock.
>
> Please check this thread out
>  http://lists.openwall.net/netdev/2015/10/31/7

OK, looks I was wrong about the lockdep benifit, :-(

But for this lock, I think lockdep isn't such important, because it is the
intermost lock, and it can be used just for protecting the bucket list
and nothing else need to be covered.


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

Re: [PATCH RESEND] infiniband:core:Add needed error path in cm_init_av_by_path

[ira.weiny]

On Tue, Dec 15, 2015 at 10:30:22AM -0700, Jason Gunthorpe wrote:
> On Tue, Dec 15, 2015 at 05:38:34PM +0100, Michael Wang wrote:
> > The hop_limit is only suggest that the package allowed to be
> > routed, not have to, correct?
> 
> If the hop limit is >= 2 (?) then the GRH is mandatory.

Yes >= 2.

"Setting this value to 0 or 1 will ensure that the packet 
will not be forwarded beyond the local subnet."

-- IBTA 8.3.6 Hop Limit

Ira

> The
> SM will return this information in the PathRecord if it determines a
> GRH is required. The whole stack follows this protocol.
> 
> The GRH is optional for in-subnet communications.
> 
> Jason
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.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] mm: memcontrol: fixed three spelling errors.

[Jiading Gai]

From: Jiading Gai 

Fixed three spelling errors.

Signed-off-by: Jiading Gai 
---
 mm/memcontrol.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index e234c21..4e424fc 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1744,7 +1744,7 @@ bool mem_cgroup_oom_synchronize(bool handle)
/*
 * There is no guarantee that an OOM-lock contender
 * sees the wakeups triggered by the OOM kill
-* uncharges.  Wake any sleepers explicitely.
+* uncharges.  Wake any sleepers explicitly.
 */
memcg_oom_recover(memcg);
}
@@ -4277,7 +4277,7 @@ mem_cgroup_css_online(struct cgroup_subsys_state *css)
page_counter_init(>memsw, NULL);
page_counter_init(>kmem, NULL);
/*
-* Deeper hierachy with use_hierarchy == false doesn't make
+* Deeper hierarchy with use_hierarchy == false doesn't make
 * much sense so let cgroup subsystem know about this
 * unfortunate state in our controller.
 */
@@ -4809,7 +4809,7 @@ static int mem_cgroup_can_attach(struct cgroup_taskset 
*tset)
return 0;
 
/*
-* We are now commited to this value whatever it is. Changes in this
+* We are now committed to this value whatever it is. Changes in this
 * tunable will only affect upcoming migrations, not the current one.
 * So we need to save it, and keep it going.
 */
-- 
1.9.1

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

RE: [PATCH 1/3] Drivers: hv: utils: fix hvt_op_poll() return value on transport destroy

[Dexuan Cui]

> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf
> Of K. Y. Srinivasan
> Sent: Wednesday, December 16, 2015 8:27
> To: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> vkuzn...@redhat.com; jasow...@redhat.com
> Subject: [PATCH 1/3] Drivers: hv: utils: fix hvt_op_poll() return value on 
> transport
> destroy
> 
> From: Vitaly Kuznetsov 
> 
> The return type of hvt_op_poll() is unsigned int and -EBADF is
> inappropriate, poll functions return POLL* statuses.
> 
> Reported-by: Dexuan Cui 
> Signed-off-by: Vitaly Kuznetsov 
> Signed-off-by: K. Y. Srinivasan 
> ---
>  drivers/hv/hv_utils_transport.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/hv/hv_utils_transport.c b/drivers/hv/hv_utils_transport.c
> index ee20b50..4f42c0e 100644
> --- a/drivers/hv/hv_utils_transport.c
> +++ b/drivers/hv/hv_utils_transport.c
> @@ -109,7 +109,7 @@ static unsigned int hvt_op_poll(struct file *file,
> poll_table *wait)
>   poll_wait(file, >outmsg_q, wait);
> 
>   if (hvt->mode == HVUTIL_TRANSPORT_DESTROY)
> - return -EBADF;
> + return POLLERR | POLLHUP;
> 
>   if (hvt->outmsg_len > 0)
>   return POLLIN | POLLRDNORM;
> --

Hi Vitaly,
The daemon only polls on POLLIN.
I'm not sure returning "POLLERR | POLLHUP" here can wake up the daemon or not.

Thanks,
-- Dexuan
--
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 07/11] KVM: page track: add notifier support

[Xiao Guangrong]

On 12/16/2015 01:53 PM, Jike Song wrote:

On 12/01/2015 02:26 AM, Xiao Guangrong wrote:

Notifier list is introduced so that any node wants to receive the track
event can register to the list

Two APIs are introduced here:
- kvm_page_track_register_notifier(): register the notifier to receive
   track event

- kvm_page_track_unregister_notifier(): stop receiving track event by
   unregister the notifier

The callback, node->track_write() is called when a write access on the
write tracked page happens

Signed-off-by: Xiao Guangrong 
---
  arch/x86/include/asm/kvm_host.h   |  1 +
  arch/x86/include/asm/kvm_page_track.h | 39 
  arch/x86/kvm/page_track.c | 67 +++
  arch/x86/kvm/x86.c|  4 +++
  4 files changed, 111 insertions(+)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index afff1f1..0f7b940 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -658,6 +658,7 @@ struct kvm_arch {
   */
  struct list_head active_mmu_pages;
  struct list_head zapped_obsolete_pages;
+struct kvm_page_track_notifier_head track_notifier_head;

  struct list_head assigned_dev_head;
  struct iommu_domain *iommu_domain;
diff --git a/arch/x86/include/asm/kvm_page_track.h 
b/arch/x86/include/asm/kvm_page_track.h
index f223201..6744234 100644
--- a/arch/x86/include/asm/kvm_page_track.h
+++ b/arch/x86/include/asm/kvm_page_track.h
@@ -6,6 +6,36 @@ enum kvm_page_track_mode {
  KVM_PAGE_TRACK_MAX,
  };

+/*
+ * The notifier represented by @kvm_page_track_notifier_node is linked into
+ * the head which will be notified when guest is triggering the track event.
+ *
+ * Write access on the head is protected by kvm->mmu_lock, read access
+ * is protected by track_srcu.
+ */
+struct kvm_page_track_notifier_head {
+struct srcu_struct track_srcu;
+struct hlist_head track_notifier_list;
+};
+
+struct kvm_page_track_notifier_node {
+struct hlist_node node;
+
+/*
+ * It is called when guest is writing the write-tracked page
+ * and write emulation is finished at that time.
+ *
+ * @vcpu: the vcpu where the write access happened.
+ * @gpa: the physical address written by guest.
+ * @new: the data was written to the address.
+ * @bytes: the written length.
+ */
+void (*track_write)(struct kvm_vcpu *vcpu, gpa_t gpa, const u8 *new,
+int bytes);


Sir, is it possible to make this non-void? as you described below, the
callback may find this gpa isn't the page being tracked, so it probably
want to return something to indicate: not my business, continue :)


Currently the return value is useless and it is not ABI so we can extend
it if it is needed in the future.

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

Re: [PATCH v4 3/5] dt/bindings: qcom_nandc: Add DT bindings

[Boris Brezillon]

Hi Archit,

Sorry for the late review, but there are a few things I think should be
addressed.

On Wed, 19 Aug 2015 10:19:04 +0530
Archit Taneja  wrote:

> Add DT bindings document for the Qualcomm NAND controller driver.
> 
> Cc: devicet...@vger.kernel.org
> 
> v4:
> - No changes
> 
> v3:
> - Don't use '0x' when specifying nand controller address space
> - Add optional property for on-flash bbt usage
> 
> Acked-by: Andy Gross 
> Signed-off-by: Archit Taneja 
> ---
>  .../devicetree/bindings/mtd/qcom_nandc.txt | 49 
> ++
>  1 file changed, 49 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt
> 
> diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt 
> b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
> new file mode 100644
> index 000..1de4643
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
> @@ -0,0 +1,49 @@
> +* Qualcomm NAND controller
> +
> +Required properties:
> +- compatible:should be "qcom,ebi2-nand" for IPQ806x
> +- reg:   MMIO address range
> +- clocks:must contain core clock and always on clock
> +- clock-names:   must contain "core" for the core clock and 
> "aon" for the
> + always on clock
> +- dmas:  DMA specifier, consisting of a phandle to the 
> ADM DMA
> + controller node and the channel number to be used for
> + NAND. Refer to dma.txt and qcom_adm.txt for more details
> +- dma-names: must be "rxtx"
> +- qcom,cmd-crci: must contain the ADM command type CRCI block instance
> + number specified for the NAND controller on the given
> + platform
> +- qcom,data-crci:must contain the ADM data type CRCI block instance
> + number specified for the NAND controller on the given
> + platform
> +
> +Optional properties:
> +- nand-bus-width:bus width. Must be 8 or 16. If not present, 8 is chosen
> + as default
> +
> +- nand-ecc-strength: number of bits to correct per ECC step. Must be 4 or 8
> + bits. If not present, 4 is chosen as default
> +- nand-on-flash-bbt: Create/use on-flash bad block table
> +
> +The device tree may optionally contain sub-nodes describing partitions of the
> +address space. See partition.txt for more detail.
> +
> +Example:
> +
> +nand@1ac0 {
> + compatible = "qcom,ebi2-nandc";
> + reg = <0x1ac0 0x800>;
> +
> + clocks = < EBI2_CLK>,
> +  < EBI2_AON_CLK>;
> + clock-names = "core", "aon";
> +
> + dmas = <_dma 3>;
> + dma-names = "rxtx";
> + qcom,cmd-crci = <15>;
> + qcom,data-crci = <3>;
> +
> + partition@0 {
> + ...
> + };
> +};


According to the registers layout defined in your driver, your NAND
controller can address multiple chips (NAND_DEV_SEL register). Since DT
bindings are supposed to be as stable as possible, I would recommend
separating the NAND controller and NAND chip declaration (as done here
[1] and here [2]).

Best Regards,

Boris

[1]http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
[2]http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/sunxi-nand.txt


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.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/

[PATCH] ahci: qoriq: Adjust the default register values on ls1021a

[Yuantian.Tang]

From: Tang Yuantian 

Updated the registers' values to enhance SATA performance and
reliability on ls1021a soc.

Signed-off-by: Tang Yuantian 
---
 drivers/ata/ahci_qoriq.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
index 256d911..7bdee9b 100644
--- a/drivers/ata/ahci_qoriq.c
+++ b/drivers/ata/ahci_qoriq.c
@@ -34,16 +34,20 @@
 
 /* port register default value */
 #define AHCI_PORT_PHY_1_CFG0xa003fffe
-#define AHCI_PORT_PHY_2_CFG0x28183411
-#define AHCI_PORT_PHY_3_CFG0x0e081004
-#define AHCI_PORT_PHY_4_CFG0x00480811
-#define AHCI_PORT_PHY_5_CFG0x192c96a4
 #define AHCI_PORT_TRANS_CFG0x0829
-#define LS1043A_PORT_PHY2  0x28184d1f
-#define LS1043A_PORT_PHY3  0x0e081509
+
+/* for ls1021a */
+#define LS1021A_PORT_PHY2  0x28183414
+#define LS1021A_PORT_PHY3  0x0e080e06
+#define LS1021A_PORT_PHY4  0x064a080b
+#define LS1021A_PORT_PHY5  0x2aa86470
 
 #define SATA_ECC_DISABLE   0x0002
 
+/* for ls1043a */
+#define LS1043A_PORT_PHY2  0x28184d1f
+#define LS1043A_PORT_PHY3  0x0e081509
+
 enum ahci_qoriq_type {
AHCI_LS1021A,
AHCI_LS1043A,
@@ -153,10 +157,10 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv 
*hpriv)
case AHCI_LS1021A:
writel(SATA_ECC_DISABLE, qpriv->ecc_addr);
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
-   writel(AHCI_PORT_PHY_2_CFG, reg_base + PORT_PHY2);
-   writel(AHCI_PORT_PHY_3_CFG, reg_base + PORT_PHY3);
-   writel(AHCI_PORT_PHY_4_CFG, reg_base + PORT_PHY4);
-   writel(AHCI_PORT_PHY_5_CFG, reg_base + PORT_PHY5);
+   writel(LS1021A_PORT_PHY2, reg_base + PORT_PHY2);
+   writel(LS1021A_PORT_PHY3, reg_base + PORT_PHY3);
+   writel(LS1021A_PORT_PHY4, reg_base + PORT_PHY4);
+   writel(LS1021A_PORT_PHY5, reg_base + PORT_PHY5);
writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
break;
 
-- 
2.1.0.27.g96db324

--
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] iommu/amd: Assign default IOMMU when there is only one IOMMU

[Suravee Suthikulpanit]

Hi Joerg,

On 12/14/2015 09:08 AM, Joerg Roedel wrote:

On Fri, Dec 11, 2015 at 04:54:38PM -0600, Suravee Suthikulpanit wrote:

Current driver makes assumption that device with devid zero is always
included in the range of devices to be managed by IOMMU. However,
certain FW does not include devid zero in IVRS table.
This has caused IOMMU perf driver to fail to initialize.


Hmm, this is a firmware bug. Is this bug seen in any systems that are
for sale?


This patch implements a workaround for this case by always assign
devid zero to be handled by the first IOMMU.


Otherwise its better to fix the firmware than to add workarounds.


Joerg



Please correct me if I am wrong. But I don't think this is necessary a 
bug in the FW. From the CZ system, here are the IVHD device entry dump 
that belong to this IOMMU:


[0.070351] AMD-Vi: device: 00:00.2 cap: 0040 seg: 0 flags: b8 info 
[0.070354] AMD-Vi:mmio-addr: feb8
[0.070384] AMD-Vi:   DEV_SELECT_RANGE_START devid: 00:01.0 flags: 00
[0.070386] AMD-Vi:   DEV_RANGE_END devid: ff:1f.6
[0.071414] AMD-Vi:   DEV_ALIAS_RANGE devid: ff:00.0 flags: 
00 devid_to: 00:14.4

[0.071417] AMD-Vi:   DEV_RANGE_END devid: ff:1f.7
[0.071423] AMD-Vi:   DEV_SPECIAL(HPET[0])devid: 00:14.0
[0.071426] AMD-Vi:   DEV_SPECIAL(IOAPIC[0])devid: 00:14.0
[0.071427] AMD-Vi:   DEV_SPECIAL(IOAPIC[1])devid: 00:00.1

And here is the output from lspci:

00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1576
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Device 1577
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. 
[AMD/ATI] Device 9874 (rev c4)

00:01.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device 9840
00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 157b
00:02.4 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 157c
00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 157b
00:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 157c
00:08.0 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device 
1578

00:09.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 157d
00:09.2 Audio device: Advanced Micro Devices, Inc. [AMD] Device 157a
00:10.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI 
Controller (rev 20)
00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA 
Controller [AHCI mode] (rev 49)
00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI 
Controller (rev 49)
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller 
(rev 4a)
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge 
(rev 11)
00:14.7 SD Host controller: Advanced Micro Devices, Inc. [AMD] FCH SD 
Flash Controller (rev 01)

00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1570
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1571
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1572
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1573
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1574
00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1575
01:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5720 
Gigabit Ethernet PCIe
01:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5720 
Gigabit Ethernet PCIe
02:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit 
SFI/SFP+ Network Connection (rev 01)
02:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit 
SFI/SFP+ Network Connection (rev 01)


The IVHD seems valid. We should not need to include from devid 0 if it 
has already specified the IOAPIC[1] separately.


Thanks,
Suravee
--
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] ntp:Change the type of time_reftime to time64_t and replace get_seconds with __ktime_get_real_seconds

[John Stultz]

On Sat, Dec 12, 2015 at 8:24 PM, DengChao  wrote:
> The type of static variant "time_reftime" and the call of get_seconds
> in ntp are both not y2038 safe.
> So change the type of time_reftime to time64_t and replace get_seconds
> with __ktime_get_real_seconds.
> The local variant "secs" in ntp_update_offset represents seconds between
> now and last ntp adjustment, it seems impossible that this time will last
> more than 68 years, so keep its type as "long".
>
> Reviewed-by: John Stultz 
> Signed-off-by: DengChao 

Reworked the commit log a bit, but queued this for testing.

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

Re: [PATCH] ntp:Fix second_overflow's input parameter type

[John Stultz]

On Sat, Dec 12, 2015 at 8:26 PM, DengChao  wrote:
> The function "second_overflow" uses "unsign long"
> as its input parameter type which will overflow after
> year 2106 on 32bit systems.
> Replace it with time64_t type.
> Because 64-bit division is expensive, since "next_ntp_leap_sec"
> has been calculated already, we can just re-use it in the
> TIME_INS/DEL cases instead of re-doing divsion which may occur
> once a second.
> Signed-off-by: DengChao 

Queued for testing. I reworded the commit message a bit too.

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

Re: [PATCH 1/2] timekeeping: Provide internal function __ktime_get_real_seconds

[John Stultz]

On Sat, Dec 12, 2015 at 8:24 PM, DengChao  wrote:
> In order to fix Y2038 issues in the ntp code we will need replace
> get_seconds() with ktime_get_real_seconds() but as the ntp code uses
> the timekeeping lock which is also used by ktime_get_real_seconds(),
> we need a version without locking.
> Add a new function __ktime_get_real_seconds() in timekeeping to
> do this.
>
> Reviewed-by: John Stultz 
> Signed-off-by: DengChao 

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

Re: [PATCH 1/1] powerpc/irq: tidy up inconsistent context in migrate_irqs()

[Daniel Axtens]

Hi,

A couple of things.

Firstly, your two email addresses don't match:

Zhang Zhuoyu  writes:
> From: Zhang Zhuoyu 

These lines do seem odd! Are they causing a problem?

I'd be more comfortable removing them if I understood why they were
added. But they've been around since the beginning of git history so
that could be a bit difficult.

Instead, would it be possible to make sure this doesn't break anything
by including some test results?

Thanks,
Daniel

> Remove paradoxical and unnecessary lines before disable local interrupt.
>
> Signed-off-by: Zhang Zhuoyu 
> ---
>  arch/powerpc/kernel/irq.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index 290559d..03fa686 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -454,8 +454,6 @@ void migrate_irqs(void)
>  
>   free_cpumask_var(mask);
>  
> - local_irq_enable();
> - mdelay(1);
>   local_irq_disable();
>  }
>  #endif
> -- 
> 1.8.3.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
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 v6 3/5] memory: mediatek: Add SMI driver

[Yong Wu]

On Tue, 2015-12-15 at 13:45 +0800, Daniel Kurtz wrote:
> Hi Yong,
> 
> On Tue, Dec 15, 2015 at 10:38 AM, Yong Wu  wrote:
> > On Mon, 2015-12-14 at 19:18 +0100, Matthias Brugger wrote:
> >> On Tuesday 08 Dec 2015 17:49:11 Yong Wu wrote:
> >> > This patch add SMI(Smart Multimedia Interface) driver. This driver
> >> > is responsible to enable/disable iommu and control the power domain
> >> > and clocks of each local arbiter.
> >> >
> >> > Signed-off-by: Yong Wu 
> >> > ---
> >> >   Currently SMI offer mtk_smi_larb_get/put to enable the power-domain
> >> > ,clocks and initialize the iommu configuration register for each a local
> >> > arbiter, The reason is:
> >> >   a) If a device would like to disable iommu, it also need call
> >> > mtk_smi_larb_get/put to enable its power and clocks.
> >> >   b) The iommu core don't support attach/detach a device within a
> >> > iommu-group. So we cann't use iommu_attach_device(iommu_detach_device)
> >> > instead
> >> > of mtk_smi_larb_get/put.
> >> >
> > [..]
> >> > +static int
> >> > +mtk_smi_enable(struct device *dev, struct clk *apb, struct clk *smi)
> >> > +{
> >> > +   int ret;
> >> > +
> >> > +   ret = pm_runtime_get_sync(dev);
> >> > +   if (ret < 0)
> >> > +   return ret;
> >> > +
> >> > +   ret = clk_prepare_enable(apb);
> >> > +   if (ret)
> >> > +   goto err_put_pm;
> >> > +
> >> > +   ret = clk_prepare_enable(smi);
> >> > +   if (ret)
> >> > +   goto err_disable_apb;
> >> > +
> >> > +   return 0;
> >> > +
> >> > +err_disable_apb:
> >> > +   clk_disable_unprepare(apb);
> >> > +err_put_pm:
> >> > +   pm_runtime_put_sync(dev);
> >> > +   return ret;
> >> > +}
> >> > +
> >> > +static void
> >> > +mtk_smi_disable(struct device *dev, struct clk *apb, struct clk *smi)
> >> > +{
> >> > +   clk_disable_unprepare(smi);
> >> > +   clk_disable_unprepare(apb);
> >> > +   pm_runtime_put_sync(dev);
> >> > +}
> >> > +
> >> > +static int mtk_smi_common_enable(struct mtk_smi_common *common)
> >> > +{
> >> > +   return mtk_smi_enable(common->dev, common->clk_apb, common->clk_smi);
> >> > +}
> >> > +
> >> > +static void mtk_smi_common_disable(struct mtk_smi_common *common)
> >> > +{
> >> > +   mtk_smi_disable(common->dev, common->clk_apb, common->clk_smi);
> >> > +}
> >> > +
> >> > +static int mtk_smi_larb_enable(struct mtk_smi_larb *larb)
> >> > +{
> >> > +   return mtk_smi_enable(larb->dev, larb->clk_apb, larb->clk_smi);
> >> > +}
> >> > +
> >> > +static void mtk_smi_larb_disable(struct mtk_smi_larb *larb)
> >> > +{
> >> > +   mtk_smi_disable(larb->dev, larb->clk_apb, larb->clk_smi);
> >> > +}
> >> > +
> >>
> >> This is somehow over-engineered. Just use mtk_smi_enable and 
> >> mtk_smi_disable
> >> instead of adding an extra indirection.
> >
> > I added this only for readable...then the code in mtk_smi_larb_get below
> > may looks simple and readable.
> >
> > If I use mtk_smi_enable/disable directly, the code will be like our
> > v5[1], is it OK?
> > Maybe I don't need these help function here, and only add more comment
> > based on v5.
> >
> > [1]
> > http://lists.linuxfoundation.org/pipermail/iommu/2015-October/014590.html
> 
> bike-shedding...
> 
> I like the fact that Yong is trying to make his helpers more type-safe.
> But, perhaps we can rename "struct mtk_smi_common" as "struct
> mtk_smi", and then make "struct mtk_smi_larb" contain a "struct
> mtk_smi":
> 
> struct mtk_smi {
>   struct device *dev;
>   struct clk *clk_apb, *clk_smi;
> }
> 
> struct mtk_smi_larb {
>   struct mtk_smi;
>   ...
> }
> 
> 
> Then, have:
> 
> int mtk_smi_enable(struct mtk_smi *smi)
> {
>   clk_enable(smi->clk_apb);
>   ...
> }
> 
> int mtk_smi_disable(struct mtk_smi *smi)
> {
> }
> 
> int mtk_smi_larb_get(struct device *larbdev)
> {
>   struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
>   struct mtk_smi *common = dev_get_drvdata(larb->smi_common_dev);
> 
>   mtk_smi_enable(common);
>   mtk_smi_enable(>smi);
>   ...
> }

Thanks. I will change like this in next time.

> 
> >>
> >> > +int mtk_smi_larb_get(struct device *larbdev)
> >> > +{
> >> > +   struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
> >> > +   struct mtk_smi_common *common = 
> >> > dev_get_drvdata(larb->smi_common_dev);
> >> > +   int ret;
> >> > +
> >> > +   ret = mtk_smi_common_enable(common);
> >> > +   if (ret)
> >> > +   return ret;
> >> > +
> >> > +   ret = mtk_smi_larb_enable(larb);
> >> > +   if (ret)
> >> > +   goto err_put_smi;
> >> > +
> >> > +   /* Configure the iommu info */
> >> > +   writel_relaxed(larb->mmu, larb->base + SMI_LARB_MMU_EN);
> 
> I think this should probably be writel() not writel_relaxed, since you
> really do want the barrier to ensure all other register accesses have
> completed before enabling the MMU.

Yes. I will fix this.

> 
> >> > +
> >> > +   return 0;
> >> > +
> >> > +err_put_smi:
> >> > +   mtk_smi_common_disable(common);
> >> > +   return ret;
> >> > +}
> >> > +
> >> > +void mtk_smi_larb_put(struct device *larbdev)
> >> > +{
> >> > +   

Re: [PATCH v6 4/5] iommu/mediatek: Add mt8173 IOMMU driver

[Yong Wu]

On Tue, 2015-12-15 at 12:37 +, Robin Murphy wrote:
> On 15/12/15 03:28, Yong Wu wrote:
> > On Mon, 2015-12-14 at 15:16 +0100, Joerg Roedel wrote:
> >> On Tue, Dec 08, 2015 at 05:49:12PM +0800, Yong Wu wrote:
> >>> +static int mtk_iommu_attach_device(struct iommu_domain *domain,
> >>> +struct device *dev)
> >>> +{
> >>> + struct mtk_iommu_domain *dom = to_mtk_domain(domain);
> >>> + struct mtk_iommu_client_priv *priv = dev->archdata.iommu;
> >>> + struct mtk_iommu_data *data;
> >>> + int ret;
> >>> +
> >>> + if (!priv)
> >>> + return -ENODEV;
> >>> +
> >>> + data = dev_get_drvdata(priv->m4udev);
> >>> + if (!data) {
> >>> + /*
> >>> +  * The DMA core will run earlier than this probe, and it will
> >>> +  * create a default iommu domain for each a iommu device.
> >>> +  * But here there is only one domain called the m4u domain
> >>> +  * which all the multimedia HW share.
> >>> +  * The default domain isn't needed here.
> >>> +  */
> >>
> >> The iommu core creates one domain per iommu-group. In your case this
> >> means one default domain per iommu in the system.
> >
> > Yes. The iommu core will create one domain per iommu-group.
> > see the next "if" here.
> >
> > But the domain here is created by the current DMA64. It's from this
> > function do_iommu_attach which will be called too early and will help
> > create a default domain for each a iommu device.(my codebase is
> > v4.4-rc1).
> 
> I still don't really understand the problem here. The M4U device is 
> created early in mtk_iommu_init_fn, so it should be probed and ready to 
> go long before anything else. Indeed, for your mtk_iommu_device_group() 
> callback to work then everything must already be happening in the right 
> order - add_device will only call iommu_group_get_for_dev() if of_xlate 
> has populated dev->archdata.iommu, and of_xlate will only do that if the 
> M4U was up and running before the client device started probing. 
> Furthermore, if mtk_iommu_device_group() *does* work, then the IOMMU 
> core will go ahead and allocate the default domain there and then, which 
> the arch code should find and use later.

Thanks. This is very helpful.

I understand your confuse right now and your expectant flow.

Our IOMMU probe was PROBE_DEFER by our SMI device, so currently it probe
was delayed, then have to add the workaround code.

Following your comment above, I test as below. Then the flows seems meet
the "best case" that the iommu core will help create default DMA domain.

@@ -664,19 +636,41 @@ static int mtk_iommu_probe(struct platform_device
*pdev)
for (i = 0; i < larb_nr; i++) {
struct device_node *larbnode;
struct platform_device *plarbdev;

larbnode = of_parse_phandle(dev->of_node, "mediatek,larbs", i);
if (!larbnode)
return -EINVAL;

plarbdev = of_find_device_by_node(larbnode);
of_node_put(larbnode);
-   if (!plarbdev)
-   return -EPROBE_DEFER;
+   if (!plarbdev) {
+   plarbdev = of_platform_device_create(larbnode,
NULL, platform_bus_type.dev_root);
+   if (IS_ERR(pdev))
+   return -EPROBE_DEFER;
+   }
}

I only add of_platform_device_create for the SMI local arbiter devices
here.

This is a big improvement for us. If this is ok, I will send a quick
next version for this.

> 
> The potential issue I *do* see, looking more closely, is that 
> iommu_group_get_for_dev() is setting group->domain but not calling the 
> attach_dev callback, which looks wrong...

This is the backtrace,

(151216_09:58:05.207)Call trace:
(151216_09:58:05.207)[] mtk_iommu_attach_device
+0xb8/0x178
(151216_09:58:05.207)[] iommu_group_add_device
+0x1d8/0x31c
(151216_09:58:05.207)[] iommu_group_get_for_dev
+0x88/0x108
(151216_09:58:05.207)[] mtk_iommu_add_device+0x14/0x34
(151216_09:58:05.207)[] add_iommu_group+0x20/0x44
(151216_09:58:05.207)[] bus_for_each_dev+0x58/0x98
(151216_09:58:05.207)[] bus_set_iommu+0x9c/0xf8

If I change like above, I will delete the workaround code..

> 
> >
> > //=the next "if"===
> > } else if (!data->m4u_dom) {
> > /*
> >  * While a device is added into a iommu group, the iommu core
> >  * will create a default domain for each a iommu group.
> >  * This default domain is reserved as the m4u domain and is
> >  * initiated here.
> >  */
> > data->m4u_dom = dom;
> > if (domain->type == IOMMU_DOMAIN_DMA) {
> > ret = iommu_dma_init_domain(domain, 0,
> > DMA_BIT_MASK(32));
> > if (ret)
> > goto err_uninit_dom;
> > }
> >
> > ret = mtk_iommu_domain_finalise(data);
> > if (ret)
> > goto err_uninit_dom;
> > }
> > //==
> >
> >>
> >>> +

Re: [PATCH 07/11] KVM: page track: add notifier support

[Jike Song]

On 12/01/2015 02:26 AM, Xiao Guangrong wrote:

Notifier list is introduced so that any node wants to receive the track
event can register to the list

Two APIs are introduced here:
- kvm_page_track_register_notifier(): register the notifier to receive
   track event

- kvm_page_track_unregister_notifier(): stop receiving track event by
   unregister the notifier

The callback, node->track_write() is called when a write access on the
write tracked page happens

Signed-off-by: Xiao Guangrong 
---
  arch/x86/include/asm/kvm_host.h   |  1 +
  arch/x86/include/asm/kvm_page_track.h | 39 
  arch/x86/kvm/page_track.c | 67 +++
  arch/x86/kvm/x86.c|  4 +++
  4 files changed, 111 insertions(+)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index afff1f1..0f7b940 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -658,6 +658,7 @@ struct kvm_arch {
 */
struct list_head active_mmu_pages;
struct list_head zapped_obsolete_pages;
+   struct kvm_page_track_notifier_head track_notifier_head;

struct list_head assigned_dev_head;
struct iommu_domain *iommu_domain;
diff --git a/arch/x86/include/asm/kvm_page_track.h 
b/arch/x86/include/asm/kvm_page_track.h
index f223201..6744234 100644
--- a/arch/x86/include/asm/kvm_page_track.h
+++ b/arch/x86/include/asm/kvm_page_track.h
@@ -6,6 +6,36 @@ enum kvm_page_track_mode {
KVM_PAGE_TRACK_MAX,
  };

+/*
+ * The notifier represented by @kvm_page_track_notifier_node is linked into
+ * the head which will be notified when guest is triggering the track event.
+ *
+ * Write access on the head is protected by kvm->mmu_lock, read access
+ * is protected by track_srcu.
+ */
+struct kvm_page_track_notifier_head {
+   struct srcu_struct track_srcu;
+   struct hlist_head track_notifier_list;
+};
+
+struct kvm_page_track_notifier_node {
+   struct hlist_node node;
+
+   /*
+* It is called when guest is writing the write-tracked page
+* and write emulation is finished at that time.
+*
+* @vcpu: the vcpu where the write access happened.
+* @gpa: the physical address written by guest.
+* @new: the data was written to the address.
+* @bytes: the written length.
+*/
+   void (*track_write)(struct kvm_vcpu *vcpu, gpa_t gpa, const u8 *new,
+   int bytes);


Sir, is it possible to make this non-void? as you described below, the
callback may find this gpa isn't the page being tracked, so it probably
want to return something to indicate: not my business, continue :)


+};
+
+void kvm_page_track_init(struct kvm *kvm);
+
  int kvm_page_track_create_memslot(struct kvm_memory_slot *slot,
  unsigned long npages);
  void kvm_page_track_free_memslot(struct kvm_memory_slot *free,
@@ -17,4 +47,13 @@ void kvm_page_track_remove_page(struct kvm *kvm, gfn_t gfn,
enum kvm_page_track_mode mode);
  bool kvm_page_track_check_mode(struct kvm_vcpu *vcpu, gfn_t gfn,
   enum kvm_page_track_mode mode);
+
+void
+kvm_page_track_register_notifier(struct kvm *kvm,
+struct kvm_page_track_notifier_node *n);
+void
+kvm_page_track_unregister_notifier(struct kvm *kvm,
+  struct kvm_page_track_notifier_node *n);
+void kvm_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa, const u8 *new,
+ int bytes);
  #endif
diff --git a/arch/x86/kvm/page_track.c b/arch/x86/kvm/page_track.c
index dc2da12..84420df 100644
--- a/arch/x86/kvm/page_track.c
+++ b/arch/x86/kvm/page_track.c
@@ -165,3 +165,70 @@ bool kvm_page_track_check_mode(struct kvm_vcpu *vcpu, 
gfn_t gfn,

return !!ACCESS_ONCE(slot->arch.gfn_track[mode][index]);
  }
+
+void kvm_page_track_init(struct kvm *kvm)
+{
+   struct kvm_page_track_notifier_head *head;
+
+   head = >arch.track_notifier_head;
+   init_srcu_struct(>track_srcu);
+   INIT_HLIST_HEAD(>track_notifier_list);
+}
+
+/*
+ * register the notifier so that event interception for the tracked guest
+ * pages can be received.
+ */
+void
+kvm_page_track_register_notifier(struct kvm *kvm,
+struct kvm_page_track_notifier_node *n)
+{
+   struct kvm_page_track_notifier_head *head;
+
+   head = >arch.track_notifier_head;
+
+   spin_lock(>mmu_lock);
+   hlist_add_head_rcu(>node, >track_notifier_list);
+   spin_unlock(>mmu_lock);
+}
+
+/*
+ * stop receiving the event interception. It is the opposed operation of
+ * kvm_page_track_register_notifier().
+ */
+void
+kvm_page_track_unregister_notifier(struct kvm *kvm,
+  struct kvm_page_track_notifier_node *n)
+{
+   struct kvm_page_track_notifier_head *head;
+
+   head = 

[PATCH 2/2] ahci: qoriq: Update the default Rx watermark value

[Yuantian.Tang]

From: Tang Yuantian 

The PTC[RXWM] sets the watermark value for Rx FIFO. The default
value 0x20 might be insufficient for some hard drives. If the
watermark value is too small, a single-cycle overflow may occur
and is reported as a CRC or internal error in the PxSERR register.
Updated the value to 0x29 according to the validation test.
All LS platforms are affected.

Signed-off-by: Tang Yuantian 
---
 drivers/ata/ahci_qoriq.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
index 4d613f8..256d911 100644
--- a/drivers/ata/ahci_qoriq.c
+++ b/drivers/ata/ahci_qoriq.c
@@ -38,7 +38,7 @@
 #define AHCI_PORT_PHY_3_CFG0x0e081004
 #define AHCI_PORT_PHY_4_CFG0x00480811
 #define AHCI_PORT_PHY_5_CFG0x192c96a4
-#define AHCI_PORT_TRANS_CFG0x0825
+#define AHCI_PORT_TRANS_CFG0x0829
 #define LS1043A_PORT_PHY2  0x28184d1f
 #define LS1043A_PORT_PHY3  0x0e081509
 
@@ -169,6 +169,7 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv *hpriv)
 
case AHCI_LS2080A:
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
+   writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
break;
}
 
-- 
2.1.0.27.g96db324

--
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] ahci: qoriq: Adjust the default register values on ls1043a

[Yuantian.Tang]

From: Tang Yuantian 

Updated the registers' values to enhance SATA performance and
reliability.

Signed-off-by: Tang Yuantian 
---
 drivers/ata/ahci_qoriq.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
index d0f9de9..4d613f8 100644
--- a/drivers/ata/ahci_qoriq.c
+++ b/drivers/ata/ahci_qoriq.c
@@ -39,6 +39,8 @@
 #define AHCI_PORT_PHY_4_CFG0x00480811
 #define AHCI_PORT_PHY_5_CFG0x192c96a4
 #define AHCI_PORT_TRANS_CFG0x0825
+#define LS1043A_PORT_PHY2  0x28184d1f
+#define LS1043A_PORT_PHY3  0x0e081509
 
 #define SATA_ECC_DISABLE   0x0002
 
@@ -159,6 +161,12 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv 
*hpriv)
break;
 
case AHCI_LS1043A:
+   writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
+   writel(LS1043A_PORT_PHY2, reg_base + PORT_PHY2);
+   writel(LS1043A_PORT_PHY3, reg_base + PORT_PHY3);
+   writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
+   break;
+
case AHCI_LS2080A:
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
break;
-- 
2.1.0.27.g96db324

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

[RFC][PATCH v3] timekeeping: Cap adjustments so they don't exceed the maxadj value

[John Stultz]

Thus its been occasionally noted that users have seen
confusing warnings like:

Adjusting tsc more than 11% (5941981 vs 7759439)

We try to limit the maximum total adjustment to 11% (10% tick
adjustment + 0.5% frequency adjustment). But this is done by
bounding the requested adjustment values, and the internal
steering that is done by tracking the error from what was
requested and what was applied, does not have any such limits.

This is usually not problematic, but in some cases has a risk
that an adjustment could cause the clocksource mult value to
overflow, so its an indication things are outside of what is
expected.

It ends up most of the reports of this 11% warning are on systems
using chrony, which utilizes the adjtimex() ADJ_TICK interface
(which allows a +-10% adjustment). The original rational for
ADJ_TICK unclear to me but my assumption it was originally added
to allow broken systems to get a big constant correction at boot
(see adjtimex userspace package for an example) which would allow
the system to work w/ ntpd's 0.5% adjustment limit.

Chrony uses ADJ_TICK to make very aggressive short term corrections
(usually right at startup). Which push us close enough to the max
bound that a few late ticks can cause the internal steering to push
past the max adjust value (tripping the warning).

Thus this patch adds some extra logic to enforce the max adjustment
cap in the internal steering.

Note: This has the potential to slow corrections when the ADJ_TICK
value is furthest away from the default value. So it would be good to
get some testing from folks using chrony, to make sure we don't
cause any troubles there.

Cc: Miroslav Lichvar 
Cc: Thomas Gleixner 
Cc: Richard Cochran 
Cc: Prarit Bhargava 
Cc: Andy Lutomirski 
Reported-by: Andy Lutomirski 
Signed-off-by: John Stultz 
---
v2: Catch single unit adjustment that was being made
repeatedly to push us past the limit, as pointed
out by Miroslav.
v3: Fix off-by-one case that could result in warning
still triggering, pointed out by Miroslav.

 kernel/time/timekeeping.c | 31 +++
 1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index d9249da..a17cdc3 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1591,9 +1591,12 @@ static __always_inline void 
timekeeping_freqadjust(struct timekeeper *tk,
 {
s64 interval = tk->cycle_interval;
s64 xinterval = tk->xtime_interval;
+   u32 base = tk->tkr_mono.clock->mult;
+   u32 max = tk->tkr_mono.clock->maxadj;
+   u32 cur_adj = tk->tkr_mono.mult;
s64 tick_error;
bool negative;
-   u32 adj;
+   u32 adj_scale;
 
/* Remove any current error adj from freq calculation */
if (tk->ntp_err_mult)
@@ -1612,13 +1615,33 @@ static __always_inline void 
timekeeping_freqadjust(struct timekeeper *tk,
/* preserve the direction of correction */
negative = (tick_error < 0);
 
-   /* Sort out the magnitude of the correction */
+   /* If any adjustment would pass the max, just return */
+   if (negative && (cur_adj - 1) <= (base - max))
+   return;
+   if (!negative && (cur_adj + 1) >= (base + max))
+   return;
+   /*
+* Sort out the magnitude of the correction, but
+* avoid making so large a correction that we go
+* over the max adjustment.
+*/
+   adj_scale = 0;
tick_error = abs(tick_error);
-   for (adj = 0; tick_error > interval; adj++)
+   while (tick_error > interval) {
+   u32 adj = 1 << (adj_scale + 1);
+
+   /* Check if adjustment gets us within 1 unit from the max */
+   if (negative && (cur_adj - adj) <= (base - max))
+   break;
+   if (!negative && (cur_adj + adj) >= (base + max))
+   break;
+
+   adj_scale++;
tick_error >>= 1;
+   }
 
/* scale the corrections */
-   timekeeping_apply_adjustment(tk, offset, negative, adj);
+   timekeeping_apply_adjustment(tk, offset, negative, adj_scale);
 }
 
 /*
-- 
1.9.1

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

linux-next: Tree for Dec 16

[Stephen Rothwell]

Hi all,

Changes since 20151215:

The drm-misc tree gained a conflict against Linus' tree.

The i2c tree gained a build failure for which I applied a patch.

The gpio tree gained a build failure so I used the version from
next-20151215.

The akpm-current tree gained a conflict against the arm64 tree.

Non-merge commits (relative to Linus' tree): 5851
 6332 files changed, 232129 insertions(+), 100546 deletions(-)



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" and checkout or reset to the new
master.

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, a
multi_v7_defconfig for arm and a native build of tools/perf. After the
final fixups (if any), I do an x86_64 modules_install followed by builds
for powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc,
sparc64 and arm defconfig.

Below is a summary of the state of the merge.

I am currently merging 231 trees (counting Linus' and 36 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

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.

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (edb42dc7bc0d Merge tag 'dmaengine-fix-4.4-rc6' of 
git://git.infradead.org/users/vkoul/slave-dma)
Merging fixes/master (25cb62b76430 Linux 4.3-rc5)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (08d4a849ee6e ARC: [plat-sim] unbork non default 
CONFIG_LINUX_LINK_BASE)
Merging arm-current/fixes (34bfbae33ae8 ARM: 8475/1: SWP emulation: Restore 
original *data when failed)
Merging m68k-current/for-linus (21d380e54c30 m68k: Wire up mlock2)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (dc9c41bd9ece Revert "powerpc/eeh: Don't unfreeze 
PHB PE after reset")
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (2c302e7e4105 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging net/master (130ed5d105dd net: fix uninitialized variable issue)
Merging ipsec/master (a8a572a6b5f2 xfrm: dst_entries_init() per-net dst_ops)
Merging ipvs/master (8e662164abb4 netfilter: nfnetlink_queue: avoid harmless 
unnitialized variable warnings)
Merging wireless-drivers/master (eeec5d0ef7ee rtlwifi: rtl8821ae: Fix lockups 
on boot)
Merging mac80211/master (cf1e05c63642 mac80211: handle width changes from 
opmode notification IE in beacon)
Merging sound-current/for-linus (b6903c0ed9f0 ALSA: hda - Add a fixup for 
Thinkpad X1 Carbon 2nd)
Merging pci-current/for-linus (5bd242f824e2 Revert "PCI: hisi: Add HiSilicon 
SoC Hip05 PCIe driver")
Merging driver-core.current/driver-core-linus (31ade3b83e18 Linux 4.4-rc3)
Merging tty.current/tty-linus (9ce119f318ba tty: Fix GPF in flush_to_ldisc())
Merging usb.current/usb-linus (9f9499ae8e64 Linux 4.4-rc5)
Merging usb-gadget-fixes/fixes (7d32cdef5356 usb: musb: fail with error when no 
DMA controller set)
Merging usb-serial-fixes/usb-linus (9f9499ae8e64 Linux 4.4-rc5)
Merging usb-chipidea-fixes/ci-for-usb-stable (6f51bc340d2a usb: chipidea: imx: 
fix a possible NULL dereference)
Merging staging.current/staging-linus (9f9499ae8e64 Linux 4.4-rc5)
Merging char-misc.current/char-misc-linus (9f9499ae8e64 Linux 4.4-rc5)
Merging input-current/for-linus (3eab4588c958 Input: elan_i2c - set input 
device's vendor and product IDs)
Merging crypto-current/master (70d906bc1750 crypto: skcipher - Copy iv from 
desc even for 0-len walks)
Merging ide/master (1b1050cdc5cd Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr())
Merging vfio-fixes/for-linus (ae5515d66362 Revert: "vfio: Include N

Re: [PATCH 1/2] mm/compaction: fix invalid free_pfn and compact_cached_free_pfn

[Joonsoo Kim]

On Tue, Dec 15, 2015 at 09:31:39AM +0100, Vlastimil Babka wrote:
> On 12/14/2015 04:26 PM, Joonsoo Kim wrote:
> >2015-12-14 19:07 GMT+09:00 Vlastimil Babka :
> >>On 12/14/2015 06:02 AM, Joonsoo Kim wrote:
> >>>
> >>
> >>Acked-by: Vlastimil Babka 
> >>
> >>Note that until now in compaction we've used basically an open-coded
> >>round_down(), and ALIGN() for rounding up. You introduce a first use of
> >>round_down(), and it would be nice to standardize on round_down() and
> >>round_up() everywhere. I think it's more obvious than open-coding and
> >>ALIGN() (which doesn't tell the reader if it's aligning up or down).
> >>Hopefully they really do the same thing and there are no caveats...
> >
> >Okay. Will send another patch for this clean-up on next spin.
> 
> Great, I didn't mean that the cleanup is needed right now, but
> whether we agree on an idiom to use whenever doing any changes from
> now on.

Okay.

> Maybe it would be best to add some defines in the top of
> compaction.c that would also hide away the repeated
> pageblock_nr_pages everywhere? Something like:
> 
> #define pageblock_start(pfn) round_down(pfn, pageblock_nr_pages)
> #define pageblock_end(pfn) round_up((pfn)+1, pageblock_nr_pages)

Quick grep shows that there are much more places this new define or
some variant can be used. It would be good clean-up. I will try it
separately.

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: livepatch: reuse module loader code to write relocations

[Jessica Yu]

+++ Jessica Yu [09/12/15 14:10 -0500]:

+++ Josh Poimboeuf [08/12/15 12:38 -0600]:

On Mon, Nov 30, 2015 at 11:21:17PM -0500, Jessica Yu wrote:

Reuse module loader code to write relocations, thereby eliminating the need
for architecture specific relocation code in livepatch. Namely, we reuse
apply_relocate_add() in the module loader to write relocations instead of
duplicating functionality in livepatch's klp_write_module_reloc(). To apply
relocation sections, remaining SHN_LIVEPATCH symbols referenced by relocs
are resolved and then apply_relocate_add() is called to apply those
relocations.

In addition, remove x86 livepatch relocation code. It is no longer needed
since symbol resolution and relocation work have been offloaded to module
loader.

Signed-off-by: Jessica Yu 
---
arch/x86/include/asm/livepatch.h |  2 -
arch/x86/kernel/Makefile |  1 -
arch/x86/kernel/livepatch.c  | 91 --
include/linux/livepatch.h| 30 ++---
include/linux/module.h   |  6 +++
kernel/livepatch/core.c  | 94 ++--
6 files changed, 70 insertions(+), 154 deletions(-)
delete mode 100644 arch/x86/kernel/livepatch.c

diff --git a/arch/x86/include/asm/livepatch.h b/arch/x86/include/asm/livepatch.h
index 19c099a..7312e25 100644
--- a/arch/x86/include/asm/livepatch.h
+++ b/arch/x86/include/asm/livepatch.h
@@ -33,8 +33,6 @@ static inline int klp_check_compiler_support(void)
#endif
return 0;
}
-int klp_write_module_reloc(struct module *mod, unsigned long type,
-  unsigned long loc, unsigned long value);

static inline void klp_arch_set_pc(struct pt_regs *regs, unsigned long ip)
{
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index b1b78ff..c5e9a5c 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -67,7 +67,6 @@ obj-$(CONFIG_X86_MPPARSE) += mpparse.o
obj-y   += apic/
obj-$(CONFIG_X86_REBOOTFIXUPS)  += reboot_fixups_32.o
obj-$(CONFIG_DYNAMIC_FTRACE)+= ftrace.o
-obj-$(CONFIG_LIVEPATCH)+= livepatch.o
obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o
obj-$(CONFIG_FTRACE_SYSCALLS)   += ftrace.o
obj-$(CONFIG_X86_TSC)   += trace_clock.o
diff --git a/arch/x86/kernel/livepatch.c b/arch/x86/kernel/livepatch.c
deleted file mode 100644
index d1d35cc..000
--- a/arch/x86/kernel/livepatch.c
+++ /dev/null
@@ -1,91 +0,0 @@
-/*
- * livepatch.c - x86-specific Kernel Live Patching Core
- *
- * Copyright (C) 2014 Seth Jennings 
- * Copyright (C) 2014 SUSE
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version 2
- * of the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, see .
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-/**
- * klp_write_module_reloc() - write a relocation in a module
- * @mod:   module in which the section to be modified is found
- * @type:  ELF relocation type (see asm/elf.h)
- * @loc:   address that the relocation should be written to
- * @value: relocation value (sym address + addend)
- *
- * This function writes a relocation to the specified location for
- * a particular module.
- */
-int klp_write_module_reloc(struct module *mod, unsigned long type,
-  unsigned long loc, unsigned long value)
-{
-   int ret, numpages, size = 4;
-   bool readonly;
-   unsigned long val;
-   unsigned long core = (unsigned long)mod->module_core;
-   unsigned long core_size = mod->core_size;
-
-   switch (type) {
-   case R_X86_64_NONE:
-   return 0;
-   case R_X86_64_64:
-   val = value;
-   size = 8;
-   break;
-   case R_X86_64_32:
-   val = (u32)value;
-   break;
-   case R_X86_64_32S:
-   val = (s32)value;
-   break;
-   case R_X86_64_PC32:
-   val = (u32)(value - loc);
-   break;
-   default:
-   /* unsupported relocation type */
-   return -EINVAL;
-   }
-
-   if (loc < core || loc >= core + core_size)
-   /* loc does not point to any symbol inside the module */
-   return -EINVAL;
-
-   readonly = false;
-
-#ifdef CONFIG_DEBUG_SET_MODULE_RONX
-   if (loc < core + mod->core_ro_size)
-   readonly = true;
-#endif
-
-   /* determine if the relocation spans a page boundary */

Re: [PATCH v3 6/7] mm/compaction: introduce migration scan limit

[Joonsoo Kim]

On Mon, Dec 14, 2015 at 10:34:50AM +0100, Vlastimil Babka wrote:
> On 12/03/2015 08:11 AM, Joonsoo Kim wrote:
> >This is preparation step to replace compaction deferring with compaction
> >limit. Whole reason why we need to replace it will be mentioned in
> >the following patch.
> >
> >In this patch, migration_scan_limit is assigned and accounted, but, not
> >checked to finish. So, there is no functional change.
> >
> >Currently, amount of migration_scan_limit is chosen to imitate compaction
> >deferring logic. We can tune it easily if overhead looks insane, but,
> >it would be further work.
> >Also, amount of migration_scan_limit is adapted by compact_defer_shift.
> >More fails increase compact_defer_shift and this will limit compaction
> >more.
> >
> >There are two interesting changes. One is that cached pfn is always
> >updated while limit is activated. Otherwise, we would scan same range
> >over and over. Second one is that async compaction is skipped while
> >limit is activated, for algorithm correctness. Until now, even if
> >failure case, sync compaction continue to work when both scanner is met
> >so COMPACT_COMPLETE usually happens in sync compaction. But, limit is
> >applied, sync compaction is finished if limit is exhausted so
> >COMPACT_COMPLETE usually happens in async compaction. Because we don't
> >consider async COMPACT_COMPLETE as actual fail while we reset cached
> >scanner pfn
> 
> I don't see where compaction being sync/async applies to "reset
> cached scanner pfn". I assume you actually meant the call to
> defer_compaction() in try_to_compact_pages, which only happens for
> async compaction?

What I wanted to say is that reset_cached_positions() is called in
__compact_finished() for async compaction and defer_compaction() isn't
called for this case.

> 
> >defer mechanism doesn't work well. And, async compaction
> >would not be easy to succeed in this case so skipping async compaction
> >doesn't result in much difference.
> 
> So, the alternative to avoiding async compaction would be to call
> defer_compaction() also when async compaction completes, right?
> Which doesn't sound as scary when deferring isn't an on/off thing,
> but applies a limit.

Yeah, it would be one alternative but I'm not sure it works well. I
can think one scenario that this doesn't work well.

1) Asume that most of pageblocks are non-movable and limit is activated.
2) Async compaction skips non-movable pageblocks and scanners are
  easily met without compaction success. Then, cache pfn is reset.
3) Sync compaction scans few pageblocks on front part of zone and
  fails due to reset cache pfn and limit.
4) 2 and 3 happen again for next compaction request.

If we allow async compaction's migration scanner to scan non-movable
pageblock in this case, everything will work fine.

How about allowing async compaction's migration scanner to scan
non-movable pageblock *always*? Reason that async compaction doesn't
scan it is to succeed compaction without much stall but it makes
compaction too complicated. For example, defer_compaction() cannot be
called for async compaction and compaction works different according to
pageblock type distribution on the system. We already have a logic to
control stall so stall would not matter now. If it doesn't work well,
we can change it by always applying scan limit to async compaction.
It could cause lower success rate on async compaction but I don't
think it causes a problem because it's not that hard to succeed to
make high-order page up to PAGE_ALLOC_COSTLY_ORDER even in non-movable
pageblock. For request more than PAGE_ALLOC_COSTLY order, we don't
need to consider success rate much because it isn't easy to succeed
on async compaction.

> This would also help the issue with THP fault compactions being only
> async and thus never deferring anything, which I think showed itself
> in Aaron's reports. This current patch wouldn't help there I think,
> as without sync compaction the system would never start to apply the

Yes, if async compaction calls defer_compaction(), Aaron's problem
would be mitigated.

> limit in the first place, and would be stuck with the ill-defined
> contended compaction detection based on need_resched etc.

I also think that contended compaction detection based on need_resched()
should be changed. If there is just one task on cpu, it isn't triggered.
It would be better to apply scan limit in this case.

Thanks.

> 
> >Signed-off-by: Joonsoo Kim 
> >---
> >  mm/compaction.c | 88 
> > +
> >  mm/internal.h   |  1 +
> >  2 files changed, 78 insertions(+), 11 deletions(-)
> >
> >diff --git a/mm/compaction.c b/mm/compaction.c
> >index 1a75a6e..b23f6d9 100644
> >--- a/mm/compaction.c
> >+++ b/mm/compaction.c
> >@@ -116,6 +116,67 @@ static struct page *pageblock_pfn_to_page(unsigned long 
> >start_pfn,
> >
> >  #ifdef CONFIG_COMPACTION
> >
> >+/*
> >+ * order == -1 is expected when compacting via
> >+ * 

[PATCH v2 5/7] f2fs: stat dirty regular/symlink inodes

[Chao Yu]

Add to stat dirty regular and symlink inode for showing in debugfs.

Signed-off-by: Chao Yu 
---
v2:
 - rename F2FS_DIRTY_DATAS to F2FS_DIRTY_DATA
---
 fs/f2fs/checkpoint.c | 4 
 fs/f2fs/debug.c  | 4 
 fs/f2fs/f2fs.h   | 8 +++-
 3 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index f33c4d7..b2af2c16 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -735,6 +735,8 @@ static void __add_dirty_inode(struct inode *inode, enum 
inode_type type)
list_add_tail(>dirty_list, >inode_list[type]);
if (type == DIR_INODE)
stat_inc_dirty_dir(sbi);
+   else
+   stat_inc_dirty_file(sbi);
 }
 
 static void __remove_dirty_inode(struct inode *inode, enum inode_type type)
@@ -751,6 +753,8 @@ static void __remove_dirty_inode(struct inode *inode, enum 
inode_type type)
clear_inode_flag(fi, flag);
if (type == DIR_INODE)
stat_dec_dirty_dir(sbi);
+   else
+   stat_dec_dirty_file(sbi);
 }
 
 void update_dirty_page(struct inode *inode, struct page *page)
diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
index f4a7b9e..780d5ed1 100644
--- a/fs/f2fs/debug.c
+++ b/fs/f2fs/debug.c
@@ -42,7 +42,9 @@ static void update_general_status(struct f2fs_sb_info *sbi)
si->ext_node = atomic_read(>total_ext_node);
si->ndirty_node = get_pages(sbi, F2FS_DIRTY_NODES);
si->ndirty_dent = get_pages(sbi, F2FS_DIRTY_DENTS);
+   si->ndirty_data = get_pages(sbi, F2FS_DIRTY_DATA);
si->ndirty_dirs = sbi->n_dirty_dirs;
+   si->ndirty_files = sbi->n_dirty_files;
si->ndirty_meta = get_pages(sbi, F2FS_DIRTY_META);
si->inmem_pages = get_pages(sbi, F2FS_INMEM_PAGES);
si->wb_pages = get_pages(sbi, F2FS_WRITEBACK);
@@ -298,6 +300,8 @@ static int stat_show(struct seq_file *s, void *v)
   si->ndirty_node, si->node_pages);
seq_printf(s, "  - dents: %4d in dirs:%4d\n",
   si->ndirty_dent, si->ndirty_dirs);
+   seq_printf(s, "  - datas: %4d in files:%4d\n",
+  si->ndirty_data, si->ndirty_files);
seq_printf(s, "  - meta: %4d in %4d\n",
   si->ndirty_meta, si->meta_pages);
seq_printf(s, "  - NATs: %9d/%9d\n  - SITs: %9d/%9d\n",
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index c68c4a3..e73ddea 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -818,6 +818,7 @@ struct f2fs_sb_info {
atomic_t inline_dir;/* # of inline_dentry inodes */
int bg_gc;  /* background gc calls */
unsigned int n_dirty_dirs;  /* # of dir inodes */
+   unsigned int n_dirty_files; /* # of regular/symlink inodes 
*/
 #endif
unsigned int last_victim[2];/* last victim segment # */
spinlock_t stat_lock;   /* lock for stat operations */
@@ -1887,7 +1888,8 @@ struct f2fs_stat_info {
unsigned long long hit_largest, hit_cached, hit_rbtree;
unsigned long long hit_total, total_ext;
int ext_tree, ext_node;
-   int ndirty_node, ndirty_dent, ndirty_dirs, ndirty_meta;
+   int ndirty_node, ndirty_meta;
+   int ndirty_dent, ndirty_dirs, ndirty_data, ndirty_files;
int nats, dirty_nats, sits, dirty_sits, fnids;
int total_count, utilization;
int bg_gc, inmem_pages, wb_pages;
@@ -1922,6 +1924,8 @@ static inline struct f2fs_stat_info *F2FS_STAT(struct 
f2fs_sb_info *sbi)
 #define stat_inc_bggc_count(sbi)   ((sbi)->bg_gc++)
 #define stat_inc_dirty_dir(sbi)((sbi)->n_dirty_dirs++)
 #define stat_dec_dirty_dir(sbi)((sbi)->n_dirty_dirs--)
+#define stat_inc_dirty_file(sbi)   ((sbi)->n_dirty_files++)
+#define stat_dec_dirty_file(sbi)   ((sbi)->n_dirty_files--)
 #define stat_inc_total_hit(sbi)
(atomic64_inc(&(sbi)->total_hit_ext))
 #define stat_inc_rbtree_node_hit(sbi)  (atomic64_inc(&(sbi)->read_hit_rbtree))
 #define stat_inc_largest_node_hit(sbi) (atomic64_inc(&(sbi)->read_hit_largest))
@@ -2004,6 +2008,8 @@ void f2fs_destroy_root_stats(void);
 #define stat_inc_bggc_count(si)
 #define stat_inc_dirty_dir(sbi)
 #define stat_dec_dirty_dir(sbi)
+#define stat_inc_dirty_file(sbi)
+#define stat_dec_dirty_file(sbi)
 #define stat_inc_total_hit(sb)
 #define stat_inc_rbtree_node_hit(sb)
 #define stat_inc_largest_node_hit(sbi)
-- 
2.6.3


--
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] f2fs: introduce __f2fs_commit_super

[Chao Yu]

Introduce __f2fs_commit_super to include duplicated codes in
f2fs_commit_super for cleanup.

Signed-off-by: Chao Yu 
---
v2:
 - clean up codes.
---
 fs/f2fs/super.c | 30 +-
 1 file changed, 13 insertions(+), 17 deletions(-)

diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 0d2d5c2..c3070c1 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -1194,14 +1194,13 @@ next:
return 0;
 }
 
-int f2fs_commit_super(struct f2fs_sb_info *sbi, bool recover)
+int __f2fs_commit_super(struct f2fs_sb_info *sbi, int block)
 {
struct f2fs_super_block *super = F2FS_RAW_SUPER(sbi);
struct buffer_head *bh;
int err;
 
-   /* write back-up superblock first */
-   bh = sb_getblk(sbi->sb, sbi->valid_super_block ? 0 : 1);
+   bh = sb_getblk(sbi->sb, block);
if (!bh)
return -EIO;
 
@@ -1215,25 +1214,22 @@ int f2fs_commit_super(struct f2fs_sb_info *sbi, bool 
recover)
err = __sync_dirty_buffer(bh, WRITE_FLUSH_FUA);
brelse(bh);
 
+   return err;
+}
+
+int f2fs_commit_super(struct f2fs_sb_info *sbi, bool recover)
+{
+   int err;
+
+   /* write back-up superblock first */
+   err = __f2fs_commit_super(sbi, sbi->valid_super_block ? 0 : 1);
+
/* if we are in recovery path, skip writing valid superblock */
if (recover || err)
return err;
 
-   bh = sb_getblk(sbi->sb, sbi->valid_super_block);
-   if (!bh)
-   return -EIO;
-
/* write current valid superblock */
-   lock_buffer(bh);
-   memcpy(bh->b_data + F2FS_SUPER_OFFSET, super, sizeof(*super));
-   set_buffer_uptodate(bh);
-   set_buffer_dirty(bh);
-   unlock_buffer(bh);
-
-   err = __sync_dirty_buffer(bh, WRITE_FLUSH_FUA);
-   brelse(bh);
-
-   return err;
+   return __f2fs_commit_super(sbi, sbi->valid_super_block);
 }
 
 static int f2fs_fill_super(struct super_block *sb, void *data, int silent)
-- 
2.6.3


--
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/1] powerpc/irq: tidy up inconsistent context in migrate_irqs()

[Zhang Zhuoyu]

From: Zhang Zhuoyu 

Remove paradoxical and unnecessary lines before disable local interrupt.

Signed-off-by: Zhang Zhuoyu 
---
 arch/powerpc/kernel/irq.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 290559d..03fa686 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -454,8 +454,6 @@ void migrate_irqs(void)
 
free_cpumask_var(mask);
 
-   local_irq_enable();
-   mdelay(1);
local_irq_disable();
 }
 #endif
-- 
1.8.3.1


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

[PATCH v2 7/7] f2fs: support data flush in checkpoint

[Chao Yu]

Previously, when finishing a checkpoint, we have persisted all fs meta
info including meta inode, node inode, dentry page of directory inode, so,
after a sudden power cut, f2fs can recover from last checkpoint with full
directory structure.

But during checkpoint, we didn't flush dirty pages of regular and symlink
inode, so such dirty datas still in memory will be lost in that moment of
power off.

In order to reduce the chance of lost data, this patch enables
f2fs_balance_fs_bg with the ability of data flushing. It will try to flush
user data before starting a checkpoint. So user's data written after last
checkpoint which may not be fsynced could be saved.

Signed-off-by: Chao Yu 
---
v2:
 - trigger data flush in f2fs_balance_fs_bg.
---
 fs/f2fs/segment.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 5fa519f..c247450 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -291,8 +291,11 @@ void f2fs_balance_fs_bg(struct f2fs_sb_info *sbi)
if (!available_free_memory(sbi, NAT_ENTRIES) ||
excess_prefree_segs(sbi) ||
!available_free_memory(sbi, INO_ENTRIES) ||
-   jiffies > sbi->cp_expires)
+   jiffies > sbi->cp_expires) {
+   if (test_opt(sbi, DATA_FLUSH))
+   sync_dirty_inodes(sbi, FILE_INODE);
f2fs_sync_fs(sbi->sb, true);
+   }
 }
 
 static int issue_flush_thread(void *data)
-- 
2.6.3


--
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 6/7] f2fs: introduce new option for controlling data flush

[Chao Yu]

Add a new option 'data_flush' to enable data flush functionality.

Signed-off-by: Chao Yu 
---
v2:
 - rebase last dev-test branch.
 - fix to set option correctly.
---
 Documentation/filesystems/f2fs.txt | 2 ++
 fs/f2fs/f2fs.h | 1 +
 fs/f2fs/super.c| 7 +++
 3 files changed, 10 insertions(+)

diff --git a/Documentation/filesystems/f2fs.txt 
b/Documentation/filesystems/f2fs.txt
index ad10494..e1c9f08 100644
--- a/Documentation/filesystems/f2fs.txt
+++ b/Documentation/filesystems/f2fs.txt
@@ -149,6 +149,8 @@ noextent_cache Disable an extent cache based on 
rb-tree explicitly, see
the above extent_cache mount option.
 noinline_data  Disable the inline data feature, inline data feature is
enabled by default.
+data_flush Enable data flushing before checkpoint in order to
+   persist data of regular and symlink.
 
 

 DEBUGFS ENTRIES
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index e73ddea..e907d9e 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -54,6 +54,7 @@
 #define F2FS_MOUNT_FASTBOOT0x1000
 #define F2FS_MOUNT_EXTENT_CACHE0x2000
 #define F2FS_MOUNT_FORCE_FG_GC 0x4000
+#define F2FS_MOUNT_DATA_FLUSH  0x8000
 
 #define clear_opt(sbi, option) (sbi->mount_opt.opt &= ~F2FS_MOUNT_##option)
 #define set_opt(sbi, option)   (sbi->mount_opt.opt |= F2FS_MOUNT_##option)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 551688e..1f7f87e 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -67,6 +67,7 @@ enum {
Opt_extent_cache,
Opt_noextent_cache,
Opt_noinline_data,
+   Opt_data_flush,
Opt_err,
 };
 
@@ -91,6 +92,7 @@ static match_table_t f2fs_tokens = {
{Opt_extent_cache, "extent_cache"},
{Opt_noextent_cache, "noextent_cache"},
{Opt_noinline_data, "noinline_data"},
+   {Opt_data_flush, "data_flush"},
{Opt_err, NULL},
 };
 
@@ -406,6 +408,9 @@ static int parse_options(struct super_block *sb, char 
*options)
case Opt_noinline_data:
clear_opt(sbi, INLINE_DATA);
break;
+   case Opt_data_flush:
+   set_opt(sbi, DATA_FLUSH);
+   break;
default:
f2fs_msg(sb, KERN_ERR,
"Unrecognized mount option \"%s\" or missing 
value",
@@ -687,6 +692,8 @@ static int f2fs_show_options(struct seq_file *seq, struct 
dentry *root)
seq_puts(seq, ",extent_cache");
else
seq_puts(seq, ",noextent_cache");
+   if (test_opt(sbi, DATA_FLUSH))
+   seq_puts(seq, ",data_flush");
seq_printf(seq, ",active_logs=%u", sbi->active_logs);
 
return 0;
-- 
2.6.3


--
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 4/7] f2fs: record dirty status of regular/symlink inode

[Chao Yu]

Maintain regular/symlink inode which has dirty pages in global dirty list
and record their total dirty pages count like the way of handling directory
inode.

Signed-off-by: Chao Yu 
---
 fs/f2fs/checkpoint.c | 66 ++--
 fs/f2fs/data.c   |  4 ++--
 fs/f2fs/dir.c|  2 +-
 fs/f2fs/f2fs.h   | 27 +
 fs/f2fs/inode.c  |  2 +-
 fs/f2fs/super.c  |  6 +++--
 6 files changed, 58 insertions(+), 49 deletions(-)

diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index a4392f0..f33c4d7 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -722,53 +722,51 @@ fail_no_cp:
return -EINVAL;
 }
 
-static void __add_dirty_inode(struct inode *inode)
+static void __add_dirty_inode(struct inode *inode, enum inode_type type)
 {
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
struct f2fs_inode_info *fi = F2FS_I(inode);
+   int flag = (type == DIR_INODE) ? FI_DIRTY_DIR : FI_DIRTY_FILE;
 
-   if (is_inode_flag_set(fi, FI_DIRTY_DIR))
+   if (is_inode_flag_set(fi, flag))
return;
 
-   set_inode_flag(fi, FI_DIRTY_DIR);
-   list_add_tail(>dirty_list, >dir_inode_list);
-   stat_inc_dirty_dir(sbi);
-   return;
+   set_inode_flag(fi, flag);
+   list_add_tail(>dirty_list, >inode_list[type]);
+   if (type == DIR_INODE)
+   stat_inc_dirty_dir(sbi);
 }
 
-static void __remove_dirty_inode(struct inode *inode)
+static void __remove_dirty_inode(struct inode *inode, enum inode_type type)
 {
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
struct f2fs_inode_info *fi = F2FS_I(inode);
+   int flag = (type == DIR_INODE) ? FI_DIRTY_DIR : FI_DIRTY_FILE;
 
if (get_dirty_pages(inode) ||
-   !is_inode_flag_set(F2FS_I(inode), FI_DIRTY_DIR))
+   !is_inode_flag_set(F2FS_I(inode), flag))
return;
 
list_del_init(>dirty_list);
-   clear_inode_flag(fi, FI_DIRTY_DIR);
-   stat_dec_dirty_dir(sbi);
+   clear_inode_flag(fi, flag);
+   if (type == DIR_INODE)
+   stat_dec_dirty_dir(sbi);
 }
 
 void update_dirty_page(struct inode *inode, struct page *page)
 {
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
+   enum inode_type type = S_ISDIR(inode->i_mode) ? DIR_INODE : FILE_INODE;
 
if (!S_ISDIR(inode->i_mode) && !S_ISREG(inode->i_mode) &&
!S_ISLNK(inode->i_mode))
return;
 
-   if (!S_ISDIR(inode->i_mode)) {
-   inode_inc_dirty_pages(inode);
-   goto out;
-   }
-
-   spin_lock(>dir_inode_lock);
-   __add_dirty_inode(inode);
+   spin_lock(>inode_lock[type]);
+   __add_dirty_inode(inode, type);
inode_inc_dirty_pages(inode);
-   spin_unlock(>dir_inode_lock);
+   spin_unlock(>inode_lock[type]);
 
-out:
SetPagePrivate(page);
f2fs_trace_pid(page);
 }
@@ -777,22 +775,24 @@ void add_dirty_dir_inode(struct inode *inode)
 {
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
 
-   spin_lock(>dir_inode_lock);
-   __add_dirty_inode(inode);
-   spin_unlock(>dir_inode_lock);
+   spin_lock(>inode_lock[DIR_INODE]);
+   __add_dirty_inode(inode, DIR_INODE);
+   spin_unlock(>inode_lock[DIR_INODE]);
 }
 
-void remove_dirty_dir_inode(struct inode *inode)
+void remove_dirty_inode(struct inode *inode)
 {
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
struct f2fs_inode_info *fi = F2FS_I(inode);
+   enum inode_type type = S_ISDIR(inode->i_mode) ? DIR_INODE : FILE_INODE;
 
-   if (!S_ISDIR(inode->i_mode))
+   if (!S_ISDIR(inode->i_mode) && !S_ISREG(inode->i_mode) &&
+   !S_ISLNK(inode->i_mode))
return;
 
-   spin_lock(>dir_inode_lock);
-   __remove_dirty_inode(inode);
-   spin_unlock(>dir_inode_lock);
+   spin_lock(>inode_lock[type]);
+   __remove_dirty_inode(inode, type);
+   spin_unlock(>inode_lock[type]);
 
/* Only from the recovery routine */
if (is_inode_flag_set(fi, FI_DELAY_IPUT)) {
@@ -801,7 +801,7 @@ void remove_dirty_dir_inode(struct inode *inode)
}
 }
 
-void sync_dirty_dir_inodes(struct f2fs_sb_info *sbi)
+void sync_dirty_inodes(struct f2fs_sb_info *sbi, enum inode_type type)
 {
struct list_head *head;
struct inode *inode;
@@ -810,16 +810,16 @@ retry:
if (unlikely(f2fs_cp_error(sbi)))
return;
 
-   spin_lock(>dir_inode_lock);
+   spin_lock(>inode_lock[type]);
 
-   head = >dir_inode_list;
+   head = >inode_list[type];
if (list_empty(head)) {
-   spin_unlock(>dir_inode_lock);
+   spin_unlock(>inode_lock[type]);
return;
}
fi = list_entry(head->next, struct f2fs_inode_info, dirty_list);
inode = igrab(>vfs_inode);
-   spin_unlock(>dir_inode_lock);
+   spin_unlock(>inode_lock[type]);
 

linux-next: manual merge of the akpm-current tree with the arm64 tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in:

  include/linux/memblock.h

between commit:

  bf3d3cc580f9 ("mm/memblock: add MEMBLOCK_NOMAP attribute to memblock memory 
table")

from the arm64 tree and commit:

  f7e2bc7d46e9 ("mm/memblock.c: memblock_is_memory()/reserved() can be boolean")

from the akpm-current 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 include/linux/memblock.h
index fec66f86eeff,359871f2fedd..
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@@ -325,10 -318,9 +325,10 @@@ phys_addr_t memblock_mem_size(unsigned 
  phys_addr_t memblock_start_of_DRAM(void);
  phys_addr_t memblock_end_of_DRAM(void);
  void memblock_enforce_memory_limit(phys_addr_t memory_limit);
- int memblock_is_memory(phys_addr_t addr);
+ bool memblock_is_memory(phys_addr_t addr);
 +int memblock_is_map_memory(phys_addr_t addr);
  int memblock_is_region_memory(phys_addr_t base, phys_addr_t size);
- int memblock_is_reserved(phys_addr_t addr);
+ bool memblock_is_reserved(phys_addr_t addr);
  bool memblock_is_region_reserved(phys_addr_t base, phys_addr_t size);
  
  extern void __memblock_dump_all(void);
--
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: denali: make MTD_NAND_DENALI_DT dependent on OF

[Masahiro Yamada]

The build passes even if CONFIG_OF is undefined, but it makes sense
to let it depend on OF.

Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 2896640..d803087 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -55,7 +55,7 @@ config MTD_NAND_DENALI_PCI
 config MTD_NAND_DENALI_DT
tristate "Support Denali NAND controller as a DT device"
select MTD_NAND_DENALI
-   depends on HAS_DMA && HAVE_CLK
+   depends on HAS_DMA && HAVE_CLK && OF
help
  Enable the driver for NAND flash on platforms using a Denali NAND
  controller as a DT device.
-- 
1.9.1

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

Re: [RFC/RFT PATCH] watchdog: Move watchdog device creation to watchdog_dev.c

[Pratyush Anand]

On 15/12/2015:06:56:50 PM, Guenter Roeck wrote:
> On 12/14/2015 12:44 PM, Wim Van Sebroeck wrote:
> >On Sun, Dec 13, 2015 at 10:24:35PM -0800, Guenter Roeck wrote:
> >
> >>On 12/13/2015 02:02 PM, Damien Riegel wrote:
> >>>On Mon, Dec 07, 2015 at 09:41:03PM +0100, Wim Van Sebroeck wrote:
> Hi All,
> 
> >On 12/07/2015 08:15 AM, Damien Riegel wrote:
> >>On Sun, Dec 06, 2015 at 11:51:41AM -0800, Guenter Roeck wrote:
> >>>The watchdog character device s currently created in
> >>>watchdog_dev.c, and the watchdog device in watchdog_core.c. This
> >>>results in cross-dependencies, as the device creation needs to
> >>>know the watchdog character device number.
> >>>
> >>>On top of that, the watchdog character device is created before
> >>>the watchdog device is created. This can result in race conditions
> >>>if the watchdog device node is accessed before the watchdog device
> >>>has been created.
> >>>
> >>>To solve the problem, move watchdog device creation into
> >>>watchdog_dev.c, and create the watchdog device prior to creating
> >>>its device node. Also move device class creation into
> >>>watchdog_dev.c, since this is now the only place where the
> >>>watchdog class is needed.
> >>>
> >>>Inspired by an earlier patch set from Damien Riegel.
> >>>
> >>>Cc: Damien Riegel 
> >>>Signed-off-by: Guenter Roeck  --- Hi Damien,
> >>>
> >>>I think this approach would be a bit better. The watchdog device
> >>>isn't really used in the watchdog core code, so it is better
> >>>created in watchdog_dev.c. That also fits well with other pending
> >>>changes, such as sysfs attribute support, and my attempts to move
> >>>the ref/unref functions completely into the watchdog core. As a
> >>>side effect, it also cleans up the error path in
> >>>__watchdog_register_device().
> >>>
> >>>What do you think ?
> >>
> >>Hi Guenter,
> >>
> >>Like the idea, but I don't really get the separation. For instance,
> >>you move watchdog_class in watchdog_dev.c but you keep watchdog_ida
> >>in watchdog_core.c whereas it is only used for device
> >>creation/deletion.
> >>
> >The class is watchdog driver internal, and it is device related, so
> >I think it made sense to move it to watchdog_dev.c. On top of that,
> >it will be needed there if/when we introduce sysfs attributes.
> >
> >The watchdog id can be determined by obtaining an id using ida, or
> >it can be provided through the watchdog alias. The operation to get
> >it is not device related, and it is not straightforward to obtain
> >it, so I thought it makes sense to keep the code in watchdog_core.c.
> >
> >Of course a lot of it is personal preference.
> >
> 
> Let me go back to how I saw the design when I created the generic
> watchdog framework: When using watchdog device drivers we need to be
> able to support the /dev/watchdog system. I also foresaw that we
> should have a sysfs interface and I saw the future for watchdog
> devices that you should be able to choose between the 2 different
> systems. You should be able to use only the /dev/watchdog interfacing,
> but you should also be able to use both a sysfs interface and a
> /dev/watchdog interface and it should even be possible to have only a
> sysfs interface in certain embedded devices. So that's why I split the
> watchdog framework over 3 files: core code, the /dev/watchdog
> interfacing and the sysfs code. Since I want to have compiled code
> small enough when choosing either /Dev/watchdog or sysfs or both this
> sounded the most logical thing to do (Unless you have a single file
> full of #ifdef-ery that becomes unreadable).
> 
> So I do not agree to have sysfs code in watchdog_dev.c . It belongs in
> watchdog_sysfs.c imho. If someone has a better idea, I'll be glad to
> listen to it and see what the benefits are. But I want a clean system
> for excluding both /dev/ (current watchdog_dev.c) and/or sysfs
> (watchdog_sysfs.c) in the future. Off-course the current behaviour is
> to have the /dev/ interface and have the option to add sysfs
> attributes.
> >>>
> >>>I agree that keeping sysfs code separate makes sense, as someone might
> >>>want to not use it.
> >>>
> >>I am not really sure about that. I don't recall a similar concern with
> >>any other subsystem.
> >>
> >>Anyway, sure, we can move the code to another file. Sure, we can add a
> >>configuration option. That means we'll also need to make several functions
> >>non-static, and possibly move some functions out of watchdog_dev.c
> >>into yet another file. But we'll need some guidance for that and an idea
> >>what is going to be acceptable.
> >>
> >>>The question is: can we make the /dev/watchdog entries optional ? That
> >>>would break the compatibility, right? Imho, it would 

linux-next: build failure after merge of the i2c tree

[Stephen Rothwell]

Hi Wolfram,

After merging the i2c tree, today's linux-next build (powerpc
ppc44x_defconfig) failed like this:

drivers/i2c/busses/i2c-ibm_iic.c:102:15: error: redefinition of 'struct 
i2c_timings'
 static struct i2c_timings {
   ^
In file included from drivers/i2c/busses/i2c-ibm_iic.c:42:0:
include/linux/i2c.h:424:8: note: originally defined here
 struct i2c_timings {
^

Caused by commit

  e1dba01ca620 ("i2c: add generic routine to parse DT for timing information")

I have applied the following patch for today:

From: Stephen Rothwell 
Date: Wed, 16 Dec 2015 15:34:10 +1100
Subject: [PATCH] ii2c: rename i2c_timings struct due to clash with generic 
version

Fixes: e1dba01ca620 ("i2c: add generic routine to parse DT for timing 
information")
Signed-off-by: Stephen Rothwell 
---
 drivers/i2c/busses/i2c-ibm_iic.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c
index ab492301581a..51154fada1df 100644
--- a/drivers/i2c/busses/i2c-ibm_iic.c
+++ b/drivers/i2c/busses/i2c-ibm_iic.c
@@ -99,7 +99,7 @@ static void dump_iic_regs(const char* header, struct 
ibm_iic_private* dev)
 #endif
 
 /* Bus timings (in ns) for bit-banging */
-static struct i2c_timings {
+static struct ibm_i2c_timings {
unsigned int hd_sta;
unsigned int su_sto;
unsigned int low;
@@ -241,7 +241,7 @@ static int iic_dc_wait(volatile struct iic_regs __iomem 
*iic, u8 mask)
 static int iic_smbus_quick(struct ibm_iic_private* dev, const struct i2c_msg* 
p)
 {
volatile struct iic_regs __iomem *iic = dev->vaddr;
-   const struct i2c_timings* t = [dev->fast_mode ? 1 : 0];
+   const struct ibm_i2c_timings* t = [dev->fast_mode ? 1 : 0];
u8 mask, v, sda;
int i, res;
 
-- 
2.6.2

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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 -next] of: Move of_io_request_and_map prototype to correct context

[Guenter Roeck]

of_io_request_and_map() is defined in of/address.c, which is compiled
if CONFIG_OF_ADDRESS is configured. However, it is defined in the context
of CONFIG_OF. This results in the following build errors for
sparc:allmodconfig (which defines CONFIG_OF but not CONFIG_OF_ADDRESS).

drivers/built-in.o: In function `meson6_timer_init':
meson6_timer.c:(.init.text+0x62a8):
undefined reference to `of_io_request_and_map'
drivers/built-in.o: In function `mtk_timer_init':
mtk_timer.c:(.init.text+0x6e70):
undefined reference to `of_io_request_and_map'
drivers/built-in.o: In function `asm9260_timer_init':
asm9260_timer.c:(.init.text+0x6fcc):
undefined reference to `of_io_request_and_map'

Move function prototype and dummy function into the CONFIG_OF_ADDRESS
conditional to fix the problem.

Exposed by commit bec8c4617611 ("clocksource/drivers/mediatek: Add the
COMPILE_TEST option").

Cc: Daniel Lezcano 
Signed-off-by: Guenter Roeck 
---
 include/linux/of_address.h | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 507daad0bc8d..b5324c0553bd 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -56,6 +56,8 @@ extern struct of_pci_range *of_pci_range_parser_one(
 extern int of_dma_get_range(struct device_node *np, u64 *dma_addr,
u64 *paddr, u64 *size);
 extern bool of_dma_is_coherent(struct device_node *np);
+void __iomem *of_io_request_and_map(struct device_node *device,
+   int index, const char *name);
 #else /* CONFIG_OF_ADDRESS */
 
 static inline u64 of_translate_address(struct device_node *np,
@@ -106,18 +108,22 @@ static inline bool of_dma_is_coherent(struct device_node 
*np)
 {
return false;
 }
+
+#include 
+
+static inline void __iomem *of_io_request_and_map(struct device_node *device,
+   int index, const char *name)
+{
+   return IOMEM_ERR_PTR(-EINVAL);
+}
 #endif /* CONFIG_OF_ADDRESS */
 
 #ifdef CONFIG_OF
 extern int of_address_to_resource(struct device_node *dev, int index,
  struct resource *r);
 void __iomem *of_iomap(struct device_node *node, int index);
-void __iomem *of_io_request_and_map(struct device_node *device,
-   int index, const char *name);
 #else
 
-#include 
-
 static inline int of_address_to_resource(struct device_node *dev, int index,
 struct resource *r)
 {
@@ -129,11 +135,6 @@ static inline void __iomem *of_iomap(struct device_node 
*device, int index)
return NULL;
 }
 
-static inline void __iomem *of_io_request_and_map(struct device_node *device,
-   int index, const char *name)
-{
-   return IOMEM_ERR_PTR(-EINVAL);
-}
 #endif
 
 #if defined(CONFIG_OF_ADDRESS) && defined(CONFIG_PCI)
-- 
2.1.4

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

[PATCH -next] irqchip: renesas-h8s: Replace ctrl_outw/ctrl_inw with writew/readw

[Guenter Roeck]

Commit 13ae42a3b1c1 ("h8300: Rename ctlr_out/in[bwl] to
raw_read/write[bwl]") changed the function names, but not all callers,
resulting in

drivers/irqchip/irq-renesas-h8s.c: In function ‘h8s_disable_irq’:
drivers/irqchip/irq-renesas-h8s.c:43:9: error:
implicit declaration of function ‘ctrl_inw’
drivers/irqchip/irq-renesas-h8s.c:44:2: error:
implicit declaration of function ‘ctrl_outw’

Fixes: 13ae42a3b1c1 ("h8300: Rename ctlr_out/in[bwl] to raw_read/write[bwl]")
Cc: Daniel Lezcano 
Signed-off-by: Guenter Roeck 
---
 drivers/irqchip/irq-renesas-h8s.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/irqchip/irq-renesas-h8s.c 
b/drivers/irqchip/irq-renesas-h8s.c
index 8098ead1eb22..af8c6c61c824 100644
--- a/drivers/irqchip/irq-renesas-h8s.c
+++ b/drivers/irqchip/irq-renesas-h8s.c
@@ -40,8 +40,8 @@ static void h8s_disable_irq(struct irq_data *data)
addr = IPRA + ((ipr_table[irq - 16] & 0xf0) >> 3);
pos = (ipr_table[irq - 16] & 0x0f) * 4;
pri = ~(0x000f << pos);
-   pri &= ctrl_inw(addr);
-   ctrl_outw(pri, addr);
+   pri &= readw(addr);
+   writew(pri, addr);
 }
 
 static void h8s_enable_irq(struct irq_data *data)
@@ -54,9 +54,9 @@ static void h8s_enable_irq(struct irq_data *data)
addr = IPRA + ((ipr_table[irq - 16] & 0xf0) >> 3);
pos = (ipr_table[irq - 16] & 0x0f) * 4;
pri = ~(0x000f << pos);
-   pri &= ctrl_inw(addr);
+   pri &= readw(addr);
pri |= 1 << pos;
-   ctrl_outw(pri, addr);
+   writew(pri, addr);
 }
 
 struct irq_chip h8s_irq_chip = {
@@ -90,7 +90,7 @@ static int __init h8s_intc_of_init(struct device_node *intc,
/* All interrupt priority is 0 (disable) */
/* IPRA to IPRK */
for (n = 0; n <= 'k' - 'a'; n++)
-   ctrl_outw(0x, IPRA + (n * 2));
+   writew(0x, IPRA + (n * 2));
 
domain = irq_domain_add_linear(intc, NR_IRQS, _ops, NULL);
BUG_ON(!domain);
-- 
2.1.4

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

Re: Information leak in sco_sock_bind

[Marcel Holtmann]

Hi Dave,

>> The following program leads to leak of 6 bytes from kernel stack:
> 
> This should fix it:
> 
> 
> [PATCH] bluetooth: Validate socket address length in sco_sock_bind().
> 
> Signed-off-by: David S. Miller 
> ---
> net/bluetooth/sco.c | 3 +++
> 1 file changed, 3 insertions(+)
> 
> diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
> index fe12966..f52bcbf 100644
> --- a/net/bluetooth/sco.c
> +++ b/net/bluetooth/sco.c
> @@ -526,6 +526,9 @@ static int sco_sock_bind(struct socket *sock, struct 
> sockaddr *addr,
>   if (!addr || addr->sa_family != AF_BLUETOOTH)
>   return -EINVAL;
> 
> + if (addr_len < sizeof(struct sockaddr_sco))
> + return -EINVAL;
> +
>   lock_sock(sk);
> 
>   if (sk->sk_state != BT_OPEN) {

thanks for the patch, but I think we do the same as we do with all the other 
Bluetooth socket and copy it into cleared stack variable. I have a patch for 
that and will ask Johan to send a pull request shortly.

Regards

Marcel

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

Re: [PATCH] drivers: md: use ktime_get_real_seconds()

[NeilBrown]

On Fri, Nov 13 2015, Deepa Dinamani wrote:

> get_seconds() API is not y2038 safe on 32 bit systems and the API
> is deprecated. Replace it with calls to ktime_get_real_seconds()
> API instead. Change mddev structure types to time64_t accordingly.
>
> 32 bit signed timestamps will overflow in the year 2038.
>
> Change the user interface mdu_array_info_s structure timestamps:
> ctime and utime values used in ioctls GET_ARRAY_INFO and
> SET_ARRAY_INFO to unsigned int. This will extend the field to last
> until the year 2106.
> The long term plan is to get rid of ctime and utime values in
> this structure as this information can be read from the on-disk
> meta data directly.
>
> Clamp the tim64_t timestamps to positive values with a max of U32_MAX
> when returning from GET_ARRAY_INFO ioctl to accommodate above changes
> in the data type of timestamps to unsigned int.
>
> v0.90 on disk meta data uses u32 for maintaining time stamps.
> So this will also last until year 2106.
> Assumption is that the usage of v0.90 will be deprecated by
> year 2106.
>
> Timestamp fields in the on disk meta data for v1.0 version already
> use 64 bit data types. Remove the truncation of the bits while
> writing to or reading from these from the disk.
>
> Signed-off-by: Deepa Dinamani 
> Reviewed-by: Arnd Bergmann 
> ---
>
> Adding the maintainer lists for md.
>
> Notes:
> A separate patch will update mdadm to obtain times from the metadata,
> and to give a deprecation warning for use of v0.90 arrays
>
>  drivers/md/md.c| 18 +-
>  drivers/md/md.h|  2 +-
>  include/uapi/linux/raid/md_u.h |  4 ++--
>  3 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 7ab9ed9..20763ea 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -1196,13 +1196,13 @@ static void super_90_sync(struct mddev *mddev, struct 
> md_rdev *rdev)
>   memcpy(>set_uuid2, mddev->uuid+8, 4);
>   memcpy(>set_uuid3, mddev->uuid+12,4);
>  
> - sb->ctime = mddev->ctime;
> + sb->ctime = clamp_t(time64_t, mddev->ctime, 0, U32_MAX);
>   sb->level = mddev->level;
>   sb->size = mddev->dev_sectors / 2;
>   sb->raid_disks = mddev->raid_disks;
>   sb->md_minor = mddev->md_minor;
>   sb->not_persistent = 0;
> - sb->utime = mddev->utime;
> + sb->utime = clamp_t(time64_t, mddev->utime, 0, U32_MAX);
>   sb->state = 0;
>   sb->events_hi = (mddev->events>>32);
>   sb->events_lo = (u32)mddev->events;
> @@ -1542,8 +1542,8 @@ static int super_1_validate(struct mddev *mddev, struct 
> md_rdev *rdev)
>   mddev->patch_version = 0;
>   mddev->external = 0;
>   mddev->chunk_sectors = le32_to_cpu(sb->chunksize);
> - mddev->ctime = le64_to_cpu(sb->ctime) & ((1ULL << 32)-1);
> - mddev->utime = le64_to_cpu(sb->utime) & ((1ULL << 32)-1);
> + mddev->ctime = le64_to_cpu(sb->ctime);
> + mddev->utime = le64_to_cpu(sb->utime);
>   mddev->level = le32_to_cpu(sb->level);
>   mddev->clevel[0] = 0;
>   mddev->layout = le32_to_cpu(sb->layout);
> @@ -2331,7 +2331,7 @@ repeat:
>  
>   spin_lock(>lock);
>  
> - mddev->utime = get_seconds();
> + mddev->utime = ktime_get_real_seconds();
>  
>   if (test_and_clear_bit(MD_CHANGE_DEVS, >flags))
>   force_change = 1;
> @@ -5828,7 +5828,7 @@ static int get_array_info(struct mddev *mddev, void 
> __user *arg)
>   info.major_version = mddev->major_version;
>   info.minor_version = mddev->minor_version;
>   info.patch_version = MD_PATCHLEVEL_VERSION;
> - info.ctime = mddev->ctime;
> + info.ctime = clamp_t(time64_t, mddev->ctime, 0, U32_MAX);
>   info.level = mddev->level;
>   info.size  = mddev->dev_sectors / 2;
>   if (info.size != mddev->dev_sectors / 2) /* overflow */
> @@ -5838,7 +5838,7 @@ static int get_array_info(struct mddev *mddev, void 
> __user *arg)
>   info.md_minor  = mddev->md_minor;
>   info.not_persistent= !mddev->persistent;
>  
> - info.utime = mddev->utime;
> + info.utime = clamp_t(time64_t, mddev->utime, 0, U32_MAX);
>   info.state = 0;
>   if (mddev->in_sync)
>   info.state = (1< @@ -6338,13 +6338,13 @@ static int set_array_info(struct mddev *mddev, 
> mdu_array_info_t *info)
>   /* ensure mddev_put doesn't delete this now that there
>* is some minimal configuration.
>*/
> - mddev->ctime = get_seconds();
> + mddev->ctime = ktime_get_real_seconds();
>   return 0;
>   }
>   mddev->major_version = MD_MAJOR_VERSION;
>   mddev->minor_version = MD_MINOR_VERSION;
>   mddev->patch_version = MD_PATCHLEVEL_VERSION;
> - mddev->ctime = get_seconds();
> + mddev->ctime = 

Re: [PATCH v5 0/3] thermal: mediatek: Add cpu dynamic power cooling model.

[Viresh Kumar]

On 16-12-15, 11:59, Dawei Chien wrote:
> Use Intelligent Power Allocation (IPA) technical to add dynamic power model
> for binding CPU thermal zone. The power allocator governor allocates power
> budget to control CPU temperature.
> 
> Power Allocator governor is able to keep SOC temperature within a defined
> temperature range to avoid SOC overheat and keep it's performance.
> mt8173-cpufreq.c need to register its' own power model with power allocator
> thermal governor, so that power allocator governor can allocates suitable
> power budget to control CPU temperature.
> 
> Binding document is refer to this patchset
> https://lkml.org/lkml/2015/11/30/239
> 
> Change since V4:
> 1. Remove unnecessary error-checking for mt8173-cpufreq.c
> 2. Initializing variable capacitance with 0

Acked-by: Viresh Kumar 

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

[PATCH] cpufreq: governor: Fix negative idle_time when configured with CONFIG_HZ_PERIODIC

[Chen Yu]

It is reported that, with CONFIG_HZ_PERIODIC=y cpu stays at the
lowest frequency even if the usage goes to 100%, neither ondemand
nor conservative governor works, however performance and
userspace work as expected. If set with CONFIG_NO_HZ_FULL=y,
everything goes well.

This problem is caused by improper calculation of the idle_time
when the load is extremely high(near 100%). Firstly, cpufreq_governor
uses get_cpu_idle_time to get the total idle time for specific cpu, then:

1.If the system is configured with CONFIG_NO_HZ_FULL, the idle time is
  returned by ktime_get, which is always increasing, it's OK.
2.However, if the system is configured with CONFIG_HZ_PERIODIC,
  get_cpu_idle_time might not guarantee to be always increasing,
  because it will leverage get_cpu_idle_time_jiffy to calculate the
  idle_time, consider the following scenario:

At T1:
idle_tick_1 = total_tick_1 - user_tick_1

sample period(80ms)...

At T2: ( T2 = T1 + 80ms):
idle_tick_2 = total_tick_2 - user_tick_2

Currently the algorithm is using (idle_tick_2 - idle_tick_1) to
get the delta idle_time during the past sample period, however
it CAN NOT guarantee that idle_tick_2 >= idle_tick_1, especially
when cpu load is high.
(Yes, total_tick_2 >= total_tick_1, and user_tick_2 >= user_tick_1,
but how about idle_tick_2 and idle_tick_1? No guarantee.)
So governor might get a negative value of idle_time during the past
sample period, which might mislead the system that the idle time is
very big(converted to unsigned int), and the busy time is nearly zero,
which causes the governor to always choose the lowest cpufreq,
then cause this problem.

In theory there are two solutions:

1.The logic should not rely on the idle tick during every sample period,
  but be based on the busy tick directly, as this is how 'top' is
  implemented.

2.Or the logic must make sure that the idle_time is strictly increasing
  during each sample period, then there would be no negative idle_time
  anymore. This solution requires minimum modification to current code
  and this patch uses method 2.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=69821
Reported-by: Jan Fikar 
Signed-off-by: Chen Yu 
---
 drivers/cpufreq/cpufreq_governor.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/cpufreq/cpufreq_governor.c 
b/drivers/cpufreq/cpufreq_governor.c
index b260576..363445f 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -84,6 +84,9 @@ void dbs_check_cpu(struct dbs_data *dbs_data, int cpu)
(cur_wall_time - j_cdbs->prev_cpu_wall);
j_cdbs->prev_cpu_wall = cur_wall_time;
 
+   if (cur_idle_time < j_cdbs->prev_cpu_idle)
+   cur_idle_time = j_cdbs->prev_cpu_idle;
+
idle_time = (unsigned int)
(cur_idle_time - j_cdbs->prev_cpu_idle);
j_cdbs->prev_cpu_idle = cur_idle_time;
-- 
1.8.4.2

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

[PATCH v11 19/19] drm: bridge: analogix/dp: Fix the possible dead lock in bridge disable time

[Yakir Yang]

It may caused a dead lock if we flush the hpd work in bridge disable time.

The normal flow would like:
  IN --> DRM IOCTL
1. Acquire crtc_ww_class_mutex (DRM IOCTL)
  IN --> analogix_dp_bridge
2. Acquire hpd work lock (Flush hpd work)
3. HPD work already in idle, no need to run the work function.
  OUT <-- analogix_dp_bridge
  OUT <-- DRM IOCTL

The dead lock flow would like:
  IN --> DRM IOCTL
1. Acquire crtc_ww_class_mutex (DRM IOCTL)
  IN --> analogix_dp_bridge
2. Acquire hpd work lock (Flush hpd work)
  IN --> analogix_dp_hotplug
  IN --> drm_helper_hpd_irq_event
3. Acquire mode_config lock (This lock already have been acquired in 
previous step 1)
** Dead Lock Now **

It's wrong to flush the hpd work in bridge->disable time, I guess the
original code just want to ensure the delay work must be finish before
encoder disabled.

The flush work in bridge disable time is try to ensure the HPD event
won't be missed before display card disabled, actually we can take a
fast respond way(interrupt thread) to update DRM HPD event to fix the
delay update and possible dead lock.

Signed-off-by: Yakir Yang 
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 62 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  3 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 26 +
 3 files changed, 55 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index bc4a9e0..c66c522 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -848,47 +848,40 @@ static void analogix_dp_enable_scramble(struct 
analogix_dp_device *dp,
}
 }
 
-static irqreturn_t analogix_dp_irq_handler(int irq, void *arg)
+static irqreturn_t analogix_dp_hardirq(int irq, void *arg)
 {
struct analogix_dp_device *dp = arg;
-
+   irqreturn_t ret = IRQ_NONE;
enum dp_irq_type irq_type;
 
irq_type = analogix_dp_get_irq_type(dp);
-   switch (irq_type) {
-   case DP_IRQ_TYPE_HP_CABLE_IN:
-   dev_dbg(dp->dev, "Received irq - cable in\n");
-   schedule_work(>hotplug_work);
-   analogix_dp_clear_hotplug_interrupts(dp);
-   break;
-   case DP_IRQ_TYPE_HP_CABLE_OUT:
-   dev_dbg(dp->dev, "Received irq - cable out\n");
-   analogix_dp_clear_hotplug_interrupts(dp);
-   break;
-   case DP_IRQ_TYPE_HP_CHANGE:
-   /*
-* We get these change notifications once in a while, but there
-* is nothing we can do with them. Just ignore it for now and
-* only handle cable changes.
-*/
-   dev_dbg(dp->dev, "Received irq - hotplug change; ignoring.\n");
-   analogix_dp_clear_hotplug_interrupts(dp);
-   break;
-   default:
-   dev_err(dp->dev, "Received irq - unknown type!\n");
-   break;
+   if (irq_type != DP_IRQ_TYPE_UNKNOWN) {
+   analogix_dp_mute_hpd_interrupt(dp);
+   ret = IRQ_WAKE_THREAD;
}
-   return IRQ_HANDLED;
+
+   return ret;
 }
 
-static void analogix_dp_hotplug(struct work_struct *work)
+static irqreturn_t analogix_dp_irq_thread(int irq, void *arg)
 {
-   struct analogix_dp_device *dp;
+   struct analogix_dp_device *dp = arg;
+   enum dp_irq_type irq_type;
+
+   irq_type = analogix_dp_get_irq_type(dp);
+   if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN ||
+   irq_type & DP_IRQ_TYPE_HP_CABLE_OUT) {
+   dev_dbg(dp->dev, "Detected cable status changed!\n");
+   if (dp->drm_dev)
+   drm_helper_hpd_irq_event(dp->drm_dev);
+   }
 
-   dp = container_of(work, struct analogix_dp_device, hotplug_work);
+   if (irq_type != DP_IRQ_TYPE_UNKNOWN) {
+   analogix_dp_clear_hotplug_interrupts(dp);
+   analogix_dp_unmute_hpd_interrupt(dp);
+   }
 
-   if (dp->drm_dev)
-   drm_helper_hpd_irq_event(dp->drm_dev);
+   return IRQ_HANDLED;
 }
 
 static void analogix_dp_commit(struct analogix_dp_device *dp)
@@ -1034,7 +1027,6 @@ static void analogix_dp_bridge_disable(struct drm_bridge 
*bridge)
}
 
disable_irq(dp->irq);
-   flush_work(>hotplug_work);
phy_power_off(dp->phy);
 
if (dp->plat_data->power_off)
@@ -1293,8 +1285,6 @@ int analogix_dp_bind(struct device *dev, struct 
drm_device *drm_dev,
return -ENODEV;
}
 
-   INIT_WORK(>hotplug_work, analogix_dp_hotplug);
-
pm_runtime_enable(dev);
 
phy_power_on(dp->phy);
@@ -1308,8 

Re: [PATCH] md: avoid warning for 32-bit sector_t

[NeilBrown]

On Tue, Nov 24 2015, Arnd Bergmann wrote:

> When CONFIG_LBDAF is not set, sector_t is only 32-bits wide, which
> means we cannot have devices with more than 2TB, and the code that
> is trying to handle compatibility support for large devices in
> md version 0.90 is meaningless but also causes a compile-time warning:
>
> drivers/md/md.c: In function 'super_90_load':
> drivers/md/md.c:1029:19: warning: large integer implicitly truncated to 
> unsigned type [-Woverflow]
> drivers/md/md.c: In function 'super_90_rdev_size_change':
> drivers/md/md.c:1323:17: warning: large integer implicitly truncated to 
> unsigned type [-Woverflow]
>
> This adds a check for CONFIG_LBDAF to avoid even getting into this
> code path, and also adds an explicit cast to let the compiler know
> it doesn't have to warn about the truncation.
>
> Signed-off-by: Arnd Bergmann 
> ---
> Noticed on ARM randconfig builds with recent gcc versions.
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 0b48c5d7c489..ee9a7ab44f32 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -1025,8 +1025,9 @@ static int super_90_load(struct md_rdev *rdev, struct 
> md_rdev *refdev, int minor
>* (not needed for Linear and RAID0 as metadata doesn't
>* record this size)
>*/
> - if (rdev->sectors >= (2ULL << 32) && sb->level >= 1)
> - rdev->sectors = (2ULL << 32) - 2;
> + if (IS_ENABLED(CONFIG_LBDAF) && (u64)rdev->sectors >= (2ULL << 32) &&
> + sb->level >= 1)
> + rdev->sectors = (sector_t)(2ULL << 32) - 2;
>  
>   if (rdev->sectors < ((sector_t)sb->size) * 2 && sb->level >= 1)
>   /* "this cannot possibly happen" ... */
> @@ -1319,8 +1320,9 @@ super_90_rdev_size_change(struct md_rdev *rdev, 
> sector_t num_sectors)
>   /* Limit to 4TB as metadata cannot record more than that.
>* 4TB == 2^32 KB, or 2*2^32 sectors.
>*/
> - if (num_sectors >= (2ULL << 32) && rdev->mddev->level >= 1)
> - num_sectors = (2ULL << 32) - 2;
> + if (IS_ENABLED(CONFIG_LBDAF) && (u64)num_sectors >= (2ULL << 32) &&
> + rdev->mddev->level >= 1)
> + num_sectors = (sector_t)(2ULL << 32) - 2;
>   md_super_write(rdev->mddev, rdev, rdev->sb_start, rdev->sb_size,
>  rdev->sb_page);
>   md_super_wait(rdev->mddev);

applied, thanks.
NeilBrown


signature.asc
Description: PGP signature

[PATCH v11 18/19] drm: bridge: analogix/dp: add panel prepare/unprepare in suspend/resume time

[Yakir Yang]

Turn off the panel power in suspend time would help to reduce
power waste.

Signed-off-by: Yakir Yang 
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index d18054d..bc4a9e0 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1357,6 +1357,12 @@ int analogix_dp_suspend(struct device *dev)
struct analogix_dp_device *dp = dev_get_drvdata(dev);
 
clk_disable_unprepare(dp->clock);
+
+   if (dp->plat_data->panel) {
+   if (drm_panel_unprepare(dp->plat_data->panel))
+   DRM_ERROR("failed to turnoff the panel\n");
+   }
+
return 0;
 }
 EXPORT_SYMBOL_GPL(analogix_dp_suspend);
@@ -1372,6 +1378,13 @@ int analogix_dp_resume(struct device *dev)
return ret;
}
 
+   if (dp->plat_data->panel) {
+   if (drm_panel_prepare(dp->plat_data->panel)) {
+   DRM_ERROR("failed to setup the panel\n");
+   return -EBUSY;
+   }
+   }
+
return 0;
 }
 EXPORT_SYMBOL_GPL(analogix_dp_resume);
-- 
1.9.1


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

[PATCH v5 1/3] thermal: mediatek: Add cpu dynamic power cooling model.

[Dawei Chien]

MT8173 cpufreq driver select of_cpufreq_power_cooling_register registering
cooling devices with dynamic power coefficient.

Signed-off-by: Dawei Chien 
---
This patch is base on patchset:
https://lkml.org/lkml/2015/11/17/251
---
 drivers/cpufreq/mt8173-cpufreq.c |   11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/mt8173-cpufreq.c b/drivers/cpufreq/mt8173-cpufreq.c
index 83001dc..d00bab5 100644
--- a/drivers/cpufreq/mt8173-cpufreq.c
+++ b/drivers/cpufreq/mt8173-cpufreq.c
@@ -263,17 +263,24 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy 
*policy,
return 0;
 }
 
+#define DYNAMIC_POWER "dynamic-power-coefficient"
+
 static void mtk_cpufreq_ready(struct cpufreq_policy *policy)
 {
struct mtk_cpu_dvfs_info *info = policy->driver_data;
struct device_node *np = of_node_get(info->cpu_dev->of_node);
+   u32 capacitance = 0;
 
if (WARN_ON(!np))
return;
 
if (of_find_property(np, "#cooling-cells", NULL)) {
-   info->cdev = of_cpufreq_cooling_register(np,
-policy->related_cpus);
+   of_property_read_u32(np, DYNAMIC_POWER, );
+
+   info->cdev = of_cpufreq_power_cooling_register(np,
+   policy->related_cpus,
+   capacitance,
+   NULL);
 
if (IS_ERR(info->cdev)) {
dev_err(info->cpu_dev,
-- 
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 v11 17/19] drm: bridge: analogix/dp: expand the look time for waiting AUX CH reply

[Yakir Yang]

After test on rockchiop platform, i found sometims driver would failed
at reading EDID message. After debugging more, i found that it's okay
to read_a byte from i2c, but it would failed at AUX transcation if we
try to ready multi-bytes from i2c.

Driver just can't received the AUX CH reply command, even no AUX error
code. I may guess that the AUX wait time is not enough, so I try to
expand the AUX wait time, and i do see this could fix the EDID read
failed at rockchip platform.

And I thought that expand the wait time won't hurt Exynos platform too
much, cause Exynos didn't have this problem, then driver would received
the reply command very soon, so no more additional wait time would bring
to Exynos platform.

Signed-off-by: Yakir Yang 
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index c7e2959..dc376bd 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -482,7 +482,7 @@ int analogix_dp_start_aux_transaction(struct 
analogix_dp_device *dp)
reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
while (!(reg & RPLY_RECEIV)) {
timeout_loop++;
-   if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
+   if (DP_TIMEOUT_LOOP_COUNT * 10 < timeout_loop) {
dev_err(dp->dev, "AUX CH command reply failed!\n");
return -ETIMEDOUT;
}
-- 
1.9.1


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

[PATCH v5 0/3] thermal: mediatek: Add cpu dynamic power cooling model.

[Dawei Chien]

Use Intelligent Power Allocation (IPA) technical to add dynamic power model
for binding CPU thermal zone. The power allocator governor allocates power
budget to control CPU temperature.

Power Allocator governor is able to keep SOC temperature within a defined
temperature range to avoid SOC overheat and keep it's performance.
mt8173-cpufreq.c need to register its' own power model with power allocator
thermal governor, so that power allocator governor can allocates suitable
power budget to control CPU temperature.

Binding document is refer to this patchset
https://lkml.org/lkml/2015/11/30/239

Change since V4:
1. Remove unnecessary error-checking for mt8173-cpufreq.c
2. Initializing variable capacitance with 0

Change since V3:
1. Remove static power model
2. Split V3's device tree in two for thermal zones and dynamic power models 
respectively

Change since V2:
1. Move dynamic/static power model in device tree

Change since V1:
1. Include mt8171.h and sort header file for mt8173.dtsi

Dawei Chien (3):
  thermal: mediatek: Add cpu dynamic power cooling model.
  arm64: dts: mt8173: Add thermal zone node.
  arm64: dts: mt8173: Add dynamic power node.

 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   47 ++
 drivers/cpufreq/mt8173-cpufreq.c |   12 ++--
 2 files changed, 57 insertions(+), 2 deletions(-)

--
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 v5 3/3] arm64: dts: mt8173: Add dynamic power node.

[Dawei Chien]

This device node is for calculating dynamic power in mW.
Since mt8173 has two clusters, there are two dynamic power
coefficient as well.

Signed-off-by: Dawei Chien 
---
This patch is base on patchset:
https://lkml.org/lkml/2015/11/17/251
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 4114cee..33fabe4 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -71,6 +71,7 @@
#cooling-cells = <2>;
#cooling-min-level = <0>;
#cooling-max-level = <7>;
+   dynamic-power-coefficient = <263>;
};
 
cpu1: cpu@1 {
@@ -95,6 +96,7 @@
#cooling-cells = <2>;
#cooling-min-level = <0>;
#cooling-max-level = <7>;
+   dynamic-power-coefficient = <263>;
};
 
cpu2: cpu@100 {
@@ -119,6 +121,7 @@
#cooling-cells = <2>;
#cooling-min-level = <0>;
#cooling-max-level = <7>;
+   dynamic-power-coefficient = <530>;
};
 
cpu3: cpu@101 {
@@ -143,6 +146,7 @@
#cooling-cells = <2>;
#cooling-min-level = <0>;
#cooling-max-level = <7>;
+   dynamic-power-coefficient = <530>;
};
 
idle-states {
-- 
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 v5 2/3] arm64: dts: mt8173: Add thermal zone node.

[Dawei Chien]

This adds thermal zone node to Mediatek MT8173 dtsi file.

Signed-off-by: Dawei Chien 
---
This patch is base on patchset:
https://lkml.org/lkml/2015/11/30/239
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   43 ++
 1 file changed, 43 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index fda805d..4114cee 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -188,6 +188,49 @@
clock-output-names = "cpum_ck";
};
 
+   thermal-zones {
+   cpu_thermal: cpu_thermal {
+   polling-delay-passive = <1000>; /* milliseconds */
+   polling-delay = <1000>; /* milliseconds */
+
+   thermal-sensors = < 0>;
+   sustainable-power = <1500>; /* milliwatts */
+
+   trips {
+   threshold: trip-point@0 {
+   temperature = <68000>;
+   hysteresis = <2000>;
+   type = "passive";
+   };
+
+   target: trip-point@1 {
+   temperature = <85000>;
+   hysteresis = <2000>;
+   type = "passive";
+   };
+
+   cpu_crit: cpu_crit@0 {
+   temperature = <115000>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+
+   cooling-maps {
+   map@0 {
+   trip = <>;
+   cooling-device = < 0 0>;
+   contribution = <1024>;
+   };
+   map@1 {
+   trip = <>;
+   cooling-device = < 0 0>;
+   contribution = <2048>;
+   };
+   };
+   };
+   };
+
timer {
compatible = "arm,armv8-timer";
interrupt-parent = <>;
-- 
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/7] mm: memcontrol: charge swap to cgroup2

[Kamezawa Hiroyuki]

On 2015/12/16 2:21, Michal Hocko wrote:
 

I completely agree that malicious/untrusted users absolutely have to
be capped by the hard limit. Then the separate swap limit would work
for sure. But I am less convinced about usefulness of the rigid (to
the global memory pressure) swap limit without the hard limit. All the
memory that could have been swapped out will make a memory pressure to
the rest of the system without being punished for it too much. Memcg
is allowed to grow over the high limit (in the current implementation)
without any way to shrink back in other words.

My understanding was that the primary use case for the swap limit is to
handle potential (not only malicious but also unexpectedly misbehaving
application) anon memory consumption runaways more gracefully without
the massive disruption on the global level. I simply didn't see swap
space partitioning as important enough because an alternative to swap
usage is to consume primary memory which is a more precious resource
IMO. Swap storage is really cheap and runtime expandable resource which
is not the case for the primary memory in general. Maybe there are other
use cases I am not aware of, though. Do you want to guarantee the swap
availability?



At the first implementation, NEC guy explained their use case in HPC area.
At that time, there was no swap support.

Considering 2 workloads partitioned into group A, B. total swap was 100GB.
  A: memory.limit = 40G
  B: memory.limit = 40G

Job scheduler runs applications in A and B in turn. Apps in A stops while Apps 
in B running.

If App-A requires 120GB of anonymous memory, it uses 80GB of swap. So, App-B 
can use only
20GB of swap. This can cause trouble if App-B needs 100GB of anonymous memory.
They need some knob to control amount of swap per cgroup.

The point is, at least for their customer, the swap is "resource", which should 
be under
control. With their use case, memory usage and swap usage has the same meaning. 
So,
mem+swap limit doesn't cause trouble.

Thanks,
-Kame




--
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 v11 16/19] drm: bridge: analogix/dp: add edid modes parse in get_modes method

[Yakir Yang]

Display Port monitor could support kinds of mode which indicate
in monitor edid, not just one single display resolution which
defined in panel or devivetree property display timing.

Note: Gustavo Padovan try to remove the controller and phy
power on function in bind time at bellow commit:
drm/exynos: do not start enabling DP at bind() phase

But for now driver need to read edid message in .get_modes()
function, so controller must be inited in bind time, so we
need to add controller init back.

Signed-off-by: Yakir Yang 
Tested-by: Javier Martinez Canillas 
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Call drm_panel_prepare() in .get_modes function, ensure panel should
  power on before driver try to read edid message.

Changes in v3:
- Add edid modes parse support

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 19 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 46 +++---
 2 files changed, 35 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 952c2c3..d18054d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -107,7 +107,7 @@ static unsigned char 
analogix_dp_calc_edid_check_sum(unsigned char *edid_data)
 
 static int analogix_dp_read_edid(struct analogix_dp_device *dp)
 {
-   unsigned char edid[EDID_BLOCK_LENGTH * 2];
+   unsigned char *edid = dp->edid;
unsigned int extend_block = 0;
unsigned char sum;
unsigned char test_vector;
@@ -901,12 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
DRM_ERROR("failed to disable the panel\n");
}
 
-   ret = analogix_dp_handle_edid(dp);
-   if (ret) {
-   dev_err(dp->dev, "unable to handle edid\n");
-   return;
-   }
-
ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
 dp->video_info.max_link_rate);
if (ret) {
@@ -947,8 +941,17 @@ EXPORT_SYMBOL_GPL(analogix_dp_detect);
 int analogix_dp_get_modes(struct device *dev)
 {
struct analogix_dp_device *dp = dev_get_drvdata(dev);
+   struct edid *edid = (struct edid *)dp->edid;
int num_modes = 0;
 
+   if (analogix_dp_handle_edid(dp)) {
+   dev_err(dp->dev, "unable to handle edid\n");
+   return -EINVAL;
+   }
+
+   drm_mode_connector_update_edid_property(dp->connector, edid);
+   num_modes += drm_add_edid_modes(dp->connector, edid);
+
if (dp->plat_data->panel)
num_modes += drm_panel_get_modes(dp->plat_data->panel);
 
@@ -1303,6 +1306,8 @@ int analogix_dp_bind(struct device *dev, struct 
drm_device *drm_dev,
}
}
 
+   analogix_dp_init_dp(dp);
+
ret = devm_request_irq(>dev, dp->irq, analogix_dp_irq_handler,
   irq_flags, "analogix-dp", dp);
if (ret) {
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index baa06e2..73b780e 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -20,6 +20,28 @@
 #define MAX_CR_LOOP5
 #define MAX_EQ_LOOP5
 
+/* I2C EDID Chip ID, Slave Address */
+#define I2C_EDID_DEVICE_ADDR   0x50
+#define I2C_E_EDID_DEVICE_ADDR 0x30
+
+#define EDID_BLOCK_LENGTH  0x80
+#define EDID_HEADER_PATTERN0x00
+#define EDID_EXTENSION_FLAG0x7e
+#define EDID_CHECKSUM  0x7f
+
+/* DP_MAX_LANE_COUNT */
+#define DPCD_ENHANCED_FRAME_CAP(x) (((x) >> 7) & 0x1)
+#define DPCD_MAX_LANE_COUNT(x) ((x) & 0x1f)
+
+/* DP_LANE_COUNT_SET */
+#define DPCD_LANE_COUNT_SET(x) ((x) & 0x1f)
+
+/* DP_TRAINING_LANE0_SET */
+#define DPCD_PRE_EMPHASIS_SET(x)   (((x) & 0x3) << 3)
+#define DPCD_PRE_EMPHASIS_GET(x)   (((x) >> 3) & 0x3)
+#define DPCD_VOLTAGE_SWING_SET(x)  (((x) & 0x3) << 0)
+#define DPCD_VOLTAGE_SWING_GET(x)  (((x) >> 0) & 0x3)
+
 enum link_rate_type {
LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
@@ -161,6 +183,7 @@ struct analogix_dp_device {
int dpms_mode;
int hpd_gpio;
boolforce_hpd;
+   unsigned char   edid[EDID_BLOCK_LENGTH * 2];
 
struct analogix_dp_plat_data *plat_data;
 };
@@ -260,27 +283,4 @@ int analogix_dp_is_video_stream_on(struct 
analogix_dp_device *dp);
 void 

[PATCH v11 15/19] drm: bridge: analogix/dp: move hpd detect to connector detect function

[Yakir Yang]

This change just make a little clean to make code more like
drm core expect, move hdp detect code from bridge->enable(),
and place them into connector->detect().

Note: Gustavo Padovan try to remove the controller and phy
power on function in bind time at bellow commit:
drm/exynos: do not start enabling DP at bind() phase

But for now the connector status don't hardcode to connected,
need to operate dp phy in .detect function, so we need to revert
parts if Gustavo Padovan's changes, add phy poweron
function in bind time.

Signed-off-by: Yakir Yang 
Tested-by: Javier Martinez Canillas 
---
Changes in v11:
- Revert parts of Gustavo Padovan's changes in commit:
drm/exynos: do not start enabling DP at bind() phase
  Add dp phy poweron function in bind time.
- Move the panel prepare from get_modes time to bind time, and move
  the panel unprepare from bridge->disable to unbind time. (Heiko)

Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Take Jingoo suggest, add commit messages.

Changes in v3:
- move dp hpd detect to connector detect function.

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 38 --
 1 file changed, 20 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 9eb17ce..952c2c3 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -901,12 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
DRM_ERROR("failed to disable the panel\n");
}
 
-   ret = analogix_dp_detect_hpd(dp);
-   if (ret) {
-   /* Cable has been disconnected, we're done */
-   return;
-   }
-
ret = analogix_dp_handle_edid(dp);
if (ret) {
dev_err(dp->dev, "unable to handle edid\n");
@@ -941,6 +935,11 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
 
 enum drm_connector_status analogix_dp_detect(struct device *dev, bool force)
 {
+   struct analogix_dp_device *dp = dev_get_drvdata(dev);
+
+   if (analogix_dp_detect_hpd(dp))
+   return connector_status_disconnected;
+
return connector_status_connected;
 }
 EXPORT_SYMBOL_GPL(analogix_dp_detect);
@@ -1006,13 +1005,6 @@ static void analogix_dp_bridge_enable(struct drm_bridge 
*bridge)
 
pm_runtime_get_sync(dp->dev);
 
-   if (dp->plat_data->panel) {
-   if (drm_panel_prepare(dp->plat_data->panel)) {
-   DRM_ERROR("failed to setup the panel\n");
-   return;
-   }
-   }
-
if (dp->plat_data->power_on)
dp->plat_data->power_on(dp->plat_data);
 
@@ -1045,11 +1037,6 @@ static void analogix_dp_bridge_disable(struct drm_bridge 
*bridge)
if (dp->plat_data->power_off)
dp->plat_data->power_off(dp->plat_data);
 
-   if (dp->plat_data->panel) {
-   if (drm_panel_unprepare(dp->plat_data->panel))
-   DRM_ERROR("failed to turnoff the panel\n");
-   }
-
pm_runtime_put_sync(dp->dev);
 
dp->dpms_mode = DRM_MODE_DPMS_OFF;
@@ -1307,6 +1294,15 @@ int analogix_dp_bind(struct device *dev, struct 
drm_device *drm_dev,
 
pm_runtime_enable(dev);
 
+   phy_power_on(dp->phy);
+
+   if (dp->plat_data->panel) {
+   if (drm_panel_prepare(dp->plat_data->panel)) {
+   DRM_ERROR("failed to setup the panel\n");
+   return -EBUSY;
+   }
+   }
+
ret = devm_request_irq(>dev, dp->irq, analogix_dp_irq_handler,
   irq_flags, "analogix-dp", dp);
if (ret) {
@@ -1340,6 +1336,12 @@ void analogix_dp_unbind(struct device *dev, struct 
device *master,
struct analogix_dp_device *dp = dev_get_drvdata(dev);
 
analogix_dp_bridge_disable(dp->bridge);
+
+   if (dp->plat_data->panel) {
+   if (drm_panel_unprepare(dp->plat_data->panel))
+   DRM_ERROR("failed to turnoff the panel\n");
+   }
+
pm_runtime_disable(dev);
 }
 EXPORT_SYMBOL_GPL(analogix_dp_unbind);
-- 
1.9.1


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

RE: linux-next: build failure after merge of the gpio tree

[Yendapally Reddy Dhananjaya Reddy]

Hi Stephen,

  Sorry. It's my mistake. In the first patch set, I tested it with 
"irq_clear_status_flags(irq, IRQ_NOREQUEST);" and in the v2 patch set the old 
one got in.

Regards
Dhananjay
 
-Original Message-
From: Stephen Rothwell [mailto:s...@canb.auug.org.au] 
Sent: Wednesday, December 16, 2015 9:08 AM
To: Linus Walleij
Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Yendapally Reddy 
Dhananjaya Reddy
Subject: linux-next: build failure after merge of the gpio tree

Hi Linus,

After merging the gpio tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

drivers/pinctrl/bcm/pinctrl-nsp-gpio.c: In function 'nsp_gpio_probe':
drivers/pinctrl/bcm/pinctrl-nsp-gpio.c:699:4: error: implicit declaration of 
function 'set_irq_flags' [-Werror=implicit-function-declaration]
set_irq_flags(irq, IRQF_VALID);
^
drivers/pinctrl/bcm/pinctrl-nsp-gpio.c:699:23: error: 'IRQF_VALID' undeclared 
(first use in this function)
set_irq_flags(irq, IRQF_VALID);
   ^

Caused by commit

  8bfcbbbcabe0 ("pinctrl: nsp: add gpio-a driver support for Broadcom NSP SoC")

set_irq_flags was removed before v4.3-rc2 ...

I have used the gpio tree from next-20151215 for today.

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

--
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 v11 14/19] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

[Yakir Yang]

Some edp screen do not have hpd signal, so we can't just return
failed when hpd plug in detect failed.

This is an hardware property, so we need add a devicetree property
"analogix,need-force-hpd" to indicate this sutiation.

Signed-off-by: Yakir Yang 
Acked-by: Rob Herring 
Tested-by: Javier Martinez Canillas 
---
Changes in v11:
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
- Add the ack from Rob Herring

Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- Add "analogix,need-force-hpd" to indicate whether driver need foce
  hpd when hpd detect failed.

Changes in v2: None

 .../bindings/display/bridge/analogix_dp.txt|  4 ++-
 .../bindings/display/exynos/exynos_dp.txt  |  1 +
 .../display/rockchip/analogix_dp-rockchip.txt  |  1 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 35 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  2 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  9 ++
 6 files changed, 46 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt 
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
index 7659a7a..4f2ba8c 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -22,6 +22,9 @@ Required properties for dp-controller:
from general PHY binding: Should be "dp".
 
 Optional properties for dp-controller:
+   -force-hpd:
+   Indicate driver need force hpd when hpd detect failed, this
+   is used for some eDP screen which don't have hpd signal.
-hpd-gpios:
Hotplug detect GPIO.
Indicates which GPIO should be used for hotplug detection
@@ -31,7 +34,6 @@ Optional properties for dp-controller:
* Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
* 
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
 
-
 [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
 ---
 
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt 
b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index 9905081..8800164 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -41,6 +41,7 @@ For the below properties, please refer to Analogix DP binding 
document:
-phys (required)
-phy-names (required)
-hpd-gpios (optional)
+   -analogix,need-force-hpd (optional)
-video interfaces (optional)
 
 Deprecated properties for DisplayPort:
diff --git 
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
index 04d99e3..e832ff9 100644
--- 
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
+++ 
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -32,6 +32,7 @@ For the below properties, please refer to Analogix DP binding 
document:
 - phys (required)
 - phy-names (required)
 - hpd-gpios (optional)
+- force-hpd (optional)
 ---
 
 Example:
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index f624810..9eb17ce 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -59,15 +59,38 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
*dp)
 {
int timeout_loop = 0;
 
-   while (analogix_dp_get_plug_in_status(dp) != 0) {
+   while (timeout_loop < DP_TIMEOUT_LOOP_COUNT) {
+   if (analogix_dp_get_plug_in_status(dp) == 0)
+   return 0;
+
timeout_loop++;
-   if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
-   dev_err(dp->dev, "failed to get hpd plug status\n");
-   return -ETIMEDOUT;
-   }
usleep_range(10, 11);
}
 
+   /*
+* Some edp screen do not have hpd signal, so we can't just
+* return failed when hpd plug in detect failed, DT property
+* "need-force-hpd" would indicate whether driver need this.
+*/
+   if (!dp->force_hpd)
+   return -ETIMEDOUT;
+
+   /*
+* The eDP TRM indicate that if HPD_STATUS(RO) is 0, AUX CH
+* will not work, so we need to give a force hpd action to
+* set HPD_STATUS manually.
+*/
+   dev_dbg(dp->dev, "failed to get hpd plug status, try to force hpd\n");
+
+   

[PATCH v11 13/19] drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288

[Yakir Yang]

There are some IP limit on rk3288 that only support 4 physical lanes
of 2.7/1.6 Gbps/lane, so seprate them out by device_type flag.

Signed-off-by: Yakir Yang 
Tested-by: Javier Martinez Canillas 
---
Changes in v11: None
Changes in v10:
- Remove the surplus "plat_data" check. (Heiko)
-   switch (dp->plat_data && dp->plat_data->dev_type) {
+   switch (dp->plat_data->dev_type) {

Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Seprate the link-rate and lane-count limit out with the device_type
  flag. (Thierry)

Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 33 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  4 +--
 2 files changed, 23 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index a0d97cb..f624810 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -890,8 +890,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
return;
}
 
-   ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
-dp->video_info.link_rate);
+   ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
+dp->video_info.max_link_rate);
if (ret) {
dev_err(dp->dev, "unable to do link train\n");
return;
@@ -1158,16 +1158,25 @@ static int analogix_dp_dt_parse_pdata(struct 
analogix_dp_device *dp)
struct device_node *dp_node = dp->dev->of_node;
struct video_info *video_info = >video_info;
 
-   if (of_property_read_u32(dp_node, "samsung,link-rate",
-_info->link_rate)) {
-   dev_err(dp->dev, "failed to get link-rate\n");
-   return -EINVAL;
-   }
-
-   if (of_property_read_u32(dp_node, "samsung,lane-count",
-_info->lane_count)) {
-   dev_err(dp->dev, "failed to get lane-count\n");
-   return -EINVAL;
+   switch (dp->plat_data->dev_type) {
+   case RK3288_DP:
+   /*
+* Like Rk3288 DisplayPort TRM indicate that "Main link
+* containing 4 physical lanes of 2.7/1.62 Gbps/lane".
+*/
+   video_info->max_link_rate = 0x0A;
+   video_info->max_lane_count = 0x04;
+   break;
+   case EXYNOS_DP:
+   /*
+* NOTE: those property parseing code is used for
+* providing backward compatibility for samsung platform.
+*/
+   of_property_read_u32(dp_node, "samsung,link-rate",
+_info->max_link_rate);
+   of_property_read_u32(dp_node, "samsung,lane-count",
+_info->max_lane_count);
+   break;
}
 
return 0;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 0416d23..4ec 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -129,8 +129,8 @@ struct video_info {
enum color_coefficient ycbcr_coeff;
enum color_depth color_depth;
 
-   enum link_rate_type link_rate;
-   enum link_lane_count_type lane_count;
+   enum link_rate_type max_link_rate;
+   enum link_lane_count_type max_lane_count;
 };
 
 struct link_train {
-- 
1.9.1


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

[PATCH] ideapad: Report hard block off if it is never on

[Ike Panhc]

Hardware radio switch is rare on recently ideapad and some of them
reported radio hardware blocked by error. With more and more ideapads
available in market to maintain the dmi table becomes a
never-finished job.

Therefore I am thinking an easy way to detect by response from
hardware. This patch will make driver says hardware switch is not
blocked if the response from ACPI is always radio blocked.

For an ideapad without radio switch, no matter what ACPI says, driver
will report false on hardware blocked.

For an ideapad with radio switch, if driver loaded with radio on, no
behavior is changed.

For an ideapad with radio switch and driver loaded with radio off,
driver will report unblocked falsely and network manager might not
scan if wireless driver reports blocked. Once the switch is on,
driver will report correct information.

Signed-off-by: Ike Panhc 
---
 drivers/platform/x86/ideapad-laptop.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/platform/x86/ideapad-laptop.c 
b/drivers/platform/x86/ideapad-laptop.c
index a313dfc..91ccb4e 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -482,11 +482,16 @@ static void ideapad_sync_rfk_state(struct ideapad_private 
*priv)
 {
unsigned long hw_blocked = 0;
int i;
+   static int hw_unblock_once;
 
if (priv->has_hw_rfkill_switch) {
if (read_ec_data(priv->adev->handle, VPCCMD_R_RF, _blocked))
return;
+   if (hw_blocked)
+   hw_unblock_once = 1;
hw_blocked = !hw_blocked;
+   if (!hw_unblock_once)
+   hw_blocked = 0;
}
 
for (i = 0; i < IDEAPAD_RFKILL_DEV_NUM; i++)
-- 
1.9.1

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

[PATCH v11 12/19] drm: bridge: analogix/dp: add some rk3288 special registers setting

[Yakir Yang]

RK3288 need some special registers setting, we can separate
them out by the dev_type of plat_data.

Signed-off-by: Yakir Yang 
Tested-by: Javier Martinez Canillas 
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Fix compile failed dut to phy_pd_addr variable misspell error

 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 76 ++-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 12 
 2 files changed, 60 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 861097a..21a3287 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -15,6 +15,8 @@
 #include 
 #include 
 
+#include 
+
 #include "analogix_dp_core.h"
 #include "analogix_dp_reg.h"
 
@@ -72,6 +74,14 @@ void analogix_dp_init_analog_param(struct analogix_dp_device 
*dp)
reg = SEL_24M | TX_DVDD_BIT_1_0625V;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_2);
 
+   if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP)) {
+   writel(REF_CLK_24M, dp->reg_base + ANALOGIX_DP_PLL_REG_1);
+   writel(0x95, dp->reg_base + ANALOGIX_DP_PLL_REG_2);
+   writel(0x40, dp->reg_base + ANALOGIX_DP_PLL_REG_3);
+   writel(0x58, dp->reg_base + ANALOGIX_DP_PLL_REG_4);
+   writel(0x22, dp->reg_base + ANALOGIX_DP_PLL_REG_5);
+   }
+
reg = DRIVE_DVDD_BIT_1_0625V | VCO_BIT_600_MICRO;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_3);
 
@@ -206,81 +216,85 @@ void analogix_dp_set_analog_power_down(struct 
analogix_dp_device *dp,
   bool enable)
 {
u32 reg;
+   u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
+
+   if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP))
+   phy_pd_addr = ANALOGIX_DP_PD;
 
switch (block) {
case AUX_BLOCK:
if (enable) {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg |= AUX_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
} else {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~AUX_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH0_BLOCK:
if (enable) {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH0_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
} else {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH0_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH1_BLOCK:
if (enable) {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH1_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
} else {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH1_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH2_BLOCK:
if (enable) {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH2_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
} else {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH2_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+  

[PATCHv2 1/3] thermal: setup monitor only once after handling trips

[Eduardo Valentin]

Instead of changing the monitoring setup every time after
handling each trip, this patch simplifies the monitoring
setup by moving the setup call to a place where all
trips have been treated already.

Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
V1->V2:
fixed typo
---
 drivers/thermal/thermal_core.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index d9e525c..8fa82c0 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -457,11 +457,6 @@ static void handle_thermal_trip(struct thermal_zone_device 
*tz, int trip)
handle_critical_trips(tz, trip, type);
else
handle_non_critical_trips(tz, trip, type);
-   /*
-* Alright, we handled this trip successfully.
-* So, start monitoring again.
-*/
-   monitor_thermal_zone(tz);
 }
 
 /**
@@ -547,6 +542,12 @@ void thermal_zone_device_update(struct thermal_zone_device 
*tz)
 
for (count = 0; count < tz->trips; count++)
handle_thermal_trip(tz, count);
+
+   /*
+* Alright, we handled these trips successfully.
+* So, start monitoring again.
+*/
+   monitor_thermal_zone(tz);
 }
 EXPORT_SYMBOL_GPL(thermal_zone_device_update);
 
-- 
2.5.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/

[PATCH 0/3] thermal: rework core to improve userspace interaction

[Eduardo Valentin]

Hello Rui, linux-pm

Please consider these three patches in the thermal core to improve
the interaction with userspace.

The first is already in its second version. It avoids reconfiguring
monitor period. Now the thermal core configures the monitor only
after handling all trip points.

The second is about improving emul_temp. The background here is to
allow using emul_temp, even if the thermal zone is not fully setup,
with a missing .get_temp().

The third is to improve hot trip points handling. Hot trip points
are described as notification entry points. However, we do very
little on them. This patch adds a uevent to propagate the event
to userspace. Today, we rely on thermal zone driver. I believe
having the same message coming on every thermal zone makes more
sense. However, I did not remove the .notify() callback, and it
should behave the same.

BR,

Eduardo Valentin (3):
  thermal: setup monitor only once after handling trips
  thermal: rework core to allow emul_temp to be treated as regular temp
  thermal: improve hot trip handling

 drivers/thermal/thermal_core.c | 96 ++
 1 file changed, 78 insertions(+), 18 deletions(-)

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

[PATCH 2/3] thermal: rework core to allow emul_temp to be treated as regular temp

[Eduardo Valentin]

Change the way we handle emul_temp. This is to allow
emul_temp to be used as input to exercise thermal core
properly. Now, even if .get_temp is not available,
the emul_temp can be used to emulate temperature.

Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
 drivers/thermal/thermal_core.c | 33 -
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 8fa82c0..f826589 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -472,18 +472,25 @@ static void handle_thermal_trip(struct 
thermal_zone_device *tz, int trip)
 int thermal_zone_get_temp(struct thermal_zone_device *tz, int *temp)
 {
int ret = -EINVAL;
-   int count;
-   int crit_temp = INT_MAX;
-   enum thermal_trip_type type;
+   int crit_temp = INT_MAX, real_temp = crit_temp - 1;
 
-   if (!tz || IS_ERR(tz) || !tz->ops->get_temp)
-   goto exit;
+   if (!tz || IS_ERR(tz))
+   return ret;
 
mutex_lock(>lock);
 
-   ret = tz->ops->get_temp(tz, temp);
+   /* Allow emulation if .get_temp is still not available */
+   if (tz->ops->get_temp) {
+   ret = tz->ops->get_temp(tz, temp);
+   if (!ret)
+   real_temp = *temp;
+   }
 
if (IS_ENABLED(CONFIG_THERMAL_EMULATION) && tz->emul_temperature) {
+   enum thermal_trip_type type;
+   int count;
+
+   ret = 0;
for (count = 0; count < tz->trips; count++) {
ret = tz->ops->get_trip_type(tz, count, );
if (!ret && type == THERMAL_TRIP_CRITICAL) {
@@ -498,17 +505,17 @@ int thermal_zone_get_temp(struct thermal_zone_device *tz, 
int *temp)
 * is below the critical temperature so that the emulation code
 * cannot hide critical conditions.
 */
-   if (!ret && *temp < crit_temp)
+   if (!ret && real_temp < crit_temp)
*temp = tz->emul_temperature;
}
  
mutex_unlock(>lock);
-exit:
+
return ret;
 }
 EXPORT_SYMBOL_GPL(thermal_zone_get_temp);
 
-static void update_temperature(struct thermal_zone_device *tz)
+static int update_temperature(struct thermal_zone_device *tz)
 {
int temp, ret;
 
@@ -518,7 +525,7 @@ static void update_temperature(struct thermal_zone_device 
*tz)
dev_warn(>device,
 "failed to read out thermal zone (%d)\n",
 ret);
-   return;
+   return ret;
}
 
mutex_lock(>lock);
@@ -529,17 +536,17 @@ static void update_temperature(struct thermal_zone_device 
*tz)
trace_thermal_temperature(tz);
dev_dbg(>device, "last_temperature=%d, current_temperature=%d\n",
tz->last_temperature, tz->temperature);
+
+   return 0;
 }
 
 void thermal_zone_device_update(struct thermal_zone_device *tz)
 {
int count;
 
-   if (!tz->ops->get_temp)
+   if (update_temperature(tz))
return;
 
-   update_temperature(tz);
-
for (count = 0; count < tz->trips; count++)
handle_thermal_trip(tz, count);
 
-- 
2.5.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/

[PATCH 3/3] thermal: improve hot trip handling

[Eduardo Valentin]

The idea is to add the choice to be notified only when temperature
crosses trip points. The trip points affected are the non-passive
trip points.

It will check last temperature and current temperature against
the trip point temperature and its hysteresis.
In case the check shows temperature has changed enought indicating
a trip point crossing, a uevent will be sent to userspace.

The uevent contains the thermal zone type, the current temperature,
the last temperature and the trip point in which the current temperature
now resides.

The behavior of ops->notify() callback remains the same.

Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
 drivers/thermal/thermal_core.c | 52 ++
 1 file changed, 52 insertions(+)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index f826589..924cccf 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -423,6 +423,56 @@ static void handle_non_critical_trips(struct 
thermal_zone_device *tz,
   def_governor->throttle(tz, trip);
 }
 
+static void thermal_tripped_notify(struct thermal_zone_device *tz,
+  int trip, enum thermal_trip_type trip_type,
+  int trip_temp)
+{
+   char tuv_name[THERMAL_NAME_LENGTH + 15], tuv_temp[25],
+   tuv_ltemp[25], tuv_trip[25], tuv_type[25];
+   char *msg[6] = { tuv_name, tuv_temp, tuv_ltemp, tuv_trip, tuv_type,
+   NULL };
+   int upper_trip_hyst, upper_trip_temp, trip_hyst = 0;
+   int ret = 0;
+
+   snprintf(tuv_name, sizeof(tuv_name), "THERMAL_ZONE=%s", tz->type);
+   snprintf(tuv_temp, sizeof(tuv_temp), "TEMP=%d", tz->temperature);
+   snprintf(tuv_ltemp, sizeof(tuv_ltemp), "LAST_TEMP=%d",
+tz->last_temperature);
+   snprintf(tuv_trip, sizeof(tuv_trip), "TRIP=%d", trip);
+   snprintf(tuv_type, sizeof(tuv_type), "TRIP_TYPE=%d", trip_type);
+
+   mutex_lock(>lock);
+
+   /* crossing up */
+   if (tz->last_temperature < trip_temp && trip_temp < tz->temperature)
+   kobject_uevent_env(>device.kobj, KOBJ_CHANGE, msg);
+
+   if (tz->ops->get_trip_hyst)
+   tz->ops->get_trip_hyst(tz, trip, _hyst);
+
+   /* crossing down, check for hyst */
+   trip_temp -= trip_hyst;
+   if (tz->last_temperature > trip_temp && trip_temp > tz->temperature) {
+   snprintf(tuv_trip, sizeof(tuv_trip), "TRIP=%d", trip - 1);
+   kobject_uevent_env(>device.kobj, KOBJ_CHANGE, msg);
+   }
+
+   ret = tz->ops->get_trip_temp(tz, trip + 1, _trip_temp);
+   if (ret)
+   goto unlock;
+
+   if (tz->ops->get_trip_hyst)
+   tz->ops->get_trip_hyst(tz, trip + 1, _trip_hyst);
+
+   upper_trip_temp -= upper_trip_hyst;
+   if (tz->last_temperature > upper_trip_temp &&
+   upper_trip_temp > tz->temperature)
+   kobject_uevent_env(>device.kobj, KOBJ_CHANGE, msg);
+
+unlock:
+   mutex_unlock(>lock);
+}
+
 static void handle_critical_trips(struct thermal_zone_device *tz,
int trip, enum thermal_trip_type trip_type)
 {
@@ -430,6 +480,8 @@ static void handle_critical_trips(struct 
thermal_zone_device *tz,
 
tz->ops->get_trip_temp(tz, trip, _temp);
 
+   thermal_tripped_notify(tz, trip, trip_type, trip_temp);
+
/* If we have not crossed the trip_temp, we do not care. */
if (trip_temp <= 0 || tz->temperature < trip_temp)
return;
-- 
2.5.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: [RFCv6 PATCH 03/10] sched: scheduler-driven cpu frequency selection

[Leo Yan]

Hi Steve,

On Tue, Dec 08, 2015 at 10:19:24PM -0800, Steve Muckle wrote:

[...]

> +static int cpufreq_sched_thread(void *data)
> +{
> + struct sched_param param;
> + struct cpufreq_policy *policy;
> + struct gov_data *gd;
> + unsigned int new_request = 0;
> + unsigned int last_request = 0;
> + int ret;
> +
> + policy = (struct cpufreq_policy *) data;
> + gd = policy->governor_data;
> +
> + param.sched_priority = 50;
> + ret = sched_setscheduler_nocheck(gd->task, SCHED_FIFO, );
> + if (ret) {
> + pr_warn("%s: failed to set SCHED_FIFO\n", __func__);
> + do_exit(-EINVAL);
> + } else {
> + pr_debug("%s: kthread (%d) set to SCHED_FIFO\n",
> + __func__, gd->task->pid);
> + }
> +
> + do {
> + set_current_state(TASK_INTERRUPTIBLE);
> + new_request = gd->requested_freq;
> + if (new_request == last_request) {
> + schedule();
> + } else {
> + /*
> +  * if the frequency thread sleeps while waiting to be
> +  * unthrottled, start over to check for a newer request
> +  */
> + if (finish_last_request(gd))
> + continue;
> + last_request = new_request;
> + cpufreq_sched_try_driver_target(policy, new_request);
> + }

I also think "set_current_state(TASK_INTERRUPTIBLE)" will introduce
logic error when software flow run into "else" block. The reason is
after you set state with TASK_INTERRUPTIBLE, if there have some
scheduling happen within cpufreq_sched_try_driver_target(), then the
thread will be remove from rq. But generally we suppose the thread
will be on rq and can continue run after next tick.

Juri's suggestion can fix this issue. And we can use atomic_t to
safely accessing gd->requested_freq.

[...]

Thanks,
Leo Yan
--
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 v11 11/19] drm: rockchip: vop: add bpc and color mode setting

[Yakir Yang]

From: Mark Yao 

Add bpc and color mode setting in rockchip_drm_vop driver, so
connector could try to use the edid drm_display_info to config
vop output mode.

Signed-off-by: Mark Yao 
Signed-off-by: Yakir Yang 
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Fix compiled error (Heiko)
- Using the connector display info message to configure eDP driver input
  video mode, but hard code CRTC video output mode to RGBaaa.

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 25 +++
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 32 ++---
 4 files changed, 51 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 2c82a9a..3990951 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -180,14 +180,29 @@ static void rockchip_dp_drm_encoder_mode_set(struct 
drm_encoder *encoder,
 static void rockchip_dp_drm_encoder_prepare(struct drm_encoder *encoder)
 {
struct rockchip_dp_device *dp = to_dp(encoder);
+   struct drm_connector *cn = >connector;
+   int ret = -1;
u32 val;
-   int ret;
 
-   ret = rockchip_drm_crtc_mode_config(encoder->crtc,
-   DRM_MODE_CONNECTOR_eDP,
-   ROCKCHIP_OUT_MODE_);
+   /*
+* FIXME(Yakir): driver should configure the CRTC output video
+* mode with the display information which indicated the monitor
+* support colorimetry.
+*
+* But don't know why the CRTC driver seems could only output the
+* RGBaaa rightly. For example, if connect the "innolux,n116bge"
+* eDP screen, EDID would indicated that screen only accepted the
+* 6bpc mode. But if I configure CRTC to RGB666 output, then eDP
+* screen would show a blue picture (RGB888 show a green picture).
+* But if I configure CTRC to RGBaaa, and eDP driver still keep
+* RGB666 input video mode, then screen would works prefect.
+*/
+   if (cn->display_info.color_formats & DRM_COLOR_FORMAT_RGB444)
+   ret = rockchip_drm_crtc_mode_config(encoder->crtc,
+   DRM_MODE_CONNECTOR_eDP,
+   10, DRM_COLOR_FORMAT_RGB444);
if (ret < 0) {
-   dev_err(dp->dev, "Could not set crtc mode config: %d.\n", ret);
+   dev_err(dp->dev, "Could not set crtc mode config (%d)\n", ret);
return;
}
 
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 80d6fc8..428a3c1 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -215,7 +215,7 @@ static void dw_hdmi_rockchip_encoder_commit(struct 
drm_encoder *encoder)
 static void dw_hdmi_rockchip_encoder_prepare(struct drm_encoder *encoder)
 {
rockchip_drm_crtc_mode_config(encoder->crtc, DRM_MODE_CONNECTOR_HDMIA,
- ROCKCHIP_OUT_MODE_);
+ 10, DRM_COLOR_FORMAT_RGB444);
 }
 
 static struct drm_encoder_helper_funcs dw_hdmi_rockchip_encoder_helper_funcs = 
{
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index dc4e5f0..ef1d7fb 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -59,7 +59,7 @@ void rockchip_unregister_crtc_funcs(struct drm_device *dev, 
int pipe);
 int rockchip_drm_encoder_get_mux_id(struct device_node *node,
struct drm_encoder *encoder);
 int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc, int connector_type,
- int out_mode);
+ int bpc, int color);
 int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
   struct device *dev);
 void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 5d8ae5e..9ef4a1f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1062,14 +1062,40 @@ static const struct drm_plane_funcs vop_plane_funcs = {
 
 int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc,
  int connector_type,
- int out_mode)
+ int bpc, int color)
 {
struct vop *vop = to_vop(crtc);
 
+   

[PATCH v11 10/19] dt-bindings: add document for rockchip dp phy

[Yakir Yang]

Add dt binding documentation for rockchip display port PHY.

Signed-off-by: Yakir Yang 
Acked-by: Rob Herring 
Reviewed-by: Heiko Stuebner 
---
Changes in v11:
- Correct the title of this rockchip dp phy document(Rob)
- Add the ack from Rob Herring

Changes in v10: None
Changes in v9: None
Changes in v8:
- Remove the specific address in the example node name. (Heiko)

Changes in v7:
- Simplify the commit message. (Kishon)

Changes in v6: None
Changes in v5:
- Split binding doc's from driver changes. (Rob)
- Update the rockchip,grf explain in document, and correct the clock required
  elemets in document. (Rob & Heiko)

Changes in v4: None
Changes in v3: None
Changes in v2: None

 .../devicetree/bindings/phy/rockchip-dp-phy.txt| 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt 
b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
new file mode 100644
index 000..50c4f9b
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
@@ -0,0 +1,22 @@
+Rockchip specific extensions to the Analogix Display Port PHY
+
+
+Required properties:
+- compatible : should be one of the following supported values:
+- "rockchip.rk3288-dp-phy"
+- clocks: from common clock binding: handle to dp clock.
+   of memory mapped region.
+- clock-names: from common clock binding:
+   Required elements: "24m"
+- rockchip,grf: phandle to the syscon managing the "general register files"
+- #phy-cells : from the generic PHY bindings, must be 0;
+
+Example:
+
+edp_phy: edp-phy {
+   compatible = "rockchip,rk3288-dp-phy";
+   rockchip,grf = <>;
+   clocks = < SCLK_EDP_24M>;
+   clock-names = "24m";
+   #phy-cells = <0>;
+};
-- 
1.9.1


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

[PATCH v11 09/19] phy: Add driver for rockchip Display Port PHY

[Yakir Yang]

Add phy driver for the Rockchip DisplayPort PHY module. This
is required to get DisplayPort working in Rockchip SoCs.

Signed-off-by: Yakir Yang 
Reviewed-by: Heiko Stuebner 
---
Changes in v11: None
Changes in v10:
- Fix the wrong macro value of GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK
BIT(4) -> BIT(20)

Changes in v9:
- Removed the unused the variable "res" in probe function. (Heiko)
- Removed the unused head file.

Changes in v8:
- Fix the mixed spacers on macro definitions. (Heiko)
- Remove the unnecessary empty line after clk_prepare_enable. (Heiko)

Changes in v7:
- Simply the commit message. (Kishon)
- Symmetrical enable/disbale the phy clock and power. (Kishon)

Changes in v6: None
Changes in v5:
- Remove "reg" DT property, cause driver could poweron/poweroff phy via
  the exist "grf" syscon already. And rename the example DT node from
  "edp_phy: phy@ff770274" to "edp_phy: edp-phy" directly. (Heiko)
- Add deivce_node at the front of driver, update phy_ops type from "static
  struct" to "static const struct". And correct the input paramters of
  devm_phy_create() interfaces. (Heiko)

Changes in v4:
- Add commit message, and remove the redundant rockchip_dp_phy_init()
  function, move those code to probe() method. And remove driver .owner
  number. (Kishon)

Changes in v3:
- Suggest, add rockchip dp phy driver, collect the phy clocks and
  power control. (Heiko)

Changes in v2: None

 drivers/phy/Kconfig   |   7 ++
 drivers/phy/Makefile  |   1 +
 drivers/phy/phy-rockchip-dp.c | 151 ++
 3 files changed, 159 insertions(+)
 create mode 100644 drivers/phy/phy-rockchip-dp.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 7eb5859d..7355819 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -319,6 +319,13 @@ config PHY_ROCKCHIP_USB
help
  Enable this to support the Rockchip USB 2.0 PHY.
 
+config PHY_ROCKCHIP_DP
+   tristate "Rockchip Display Port PHY Driver"
+   depends on ARCH_ROCKCHIP && OF
+   select GENERIC_PHY
+   help
+ Enable this to support the Rockchip Display Port PHY.
+
 config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 075db1a..b1700cd 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -35,6 +35,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+= 
phy-s5pv210-usb2.o
 obj-$(CONFIG_PHY_EXYNOS5_USBDRD)   += phy-exynos5-usbdrd.o
 obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
 obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
+obj-$(CONFIG_PHY_ROCKCHIP_DP)  += phy-rockchip-dp.o
 obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
 obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)   += phy-spear1310-miphy.o
 obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)   += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
new file mode 100644
index 000..3cb3bf8
--- /dev/null
+++ b/drivers/phy/phy-rockchip-dp.c
@@ -0,0 +1,151 @@
+/*
+ * Rockchip DP PHY driver
+ *
+ * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
+ * Author: Yakir Yang 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GRF_SOC_CON12   0x0274
+
+#define GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK   BIT(20)
+#define GRF_EDP_REF_CLK_SEL_INTER   BIT(4)
+
+#define GRF_EDP_PHY_SIDDQ_HIWORD_MASK   BIT(21)
+#define GRF_EDP_PHY_SIDDQ_ON0
+#define GRF_EDP_PHY_SIDDQ_OFF   BIT(5)
+
+struct rockchip_dp_phy {
+   struct device  *dev;
+   struct regmap  *grf;
+   struct clk *phy_24m;
+};
+
+static int rockchip_set_phy_state(struct phy *phy, bool enable)
+{
+   struct rockchip_dp_phy *dp = phy_get_drvdata(phy);
+   int ret;
+
+   if (enable) {
+   ret = regmap_write(dp->grf, GRF_SOC_CON12,
+  GRF_EDP_PHY_SIDDQ_HIWORD_MASK |
+  GRF_EDP_PHY_SIDDQ_ON);
+   if (ret < 0) {
+   dev_err(dp->dev, "Can't enable PHY power %d\n", ret);
+   return ret;
+   }
+
+   ret = clk_prepare_enable(dp->phy_24m);
+   } else {
+   clk_disable_unprepare(dp->phy_24m);
+
+   ret = regmap_write(dp->grf, GRF_SOC_CON12,
+  GRF_EDP_PHY_SIDDQ_HIWORD_MASK |
+  GRF_EDP_PHY_SIDDQ_OFF);
+   }
+
+   return ret;
+}
+
+static int rockchip_dp_phy_power_on(struct phy *phy)
+{
+   return rockchip_set_phy_state(phy, true);
+}
+
+static int rockchip_dp_phy_power_off(struct phy 

[PATCH v11 08/19] dt-bindings: add document for rockchip variant of analogix_dp

[Yakir Yang]

Rockchip DP driver is a helper driver of analogix_dp coder driver,
so most of the DT property should be descriped in analogix_dp document.

Signed-off-by: Yakir Yang 
Acked-by: Rob Herring 
Reviewed-by: Heiko Stuebner 
---
Changes in v11: None
Changes in v10:
- Add the ack from Rob Herring

Changes in v9:
- Document more details for 'ports' property.

Changes in v8:
- Modify the commit subject name. (Heiko)

Changes in v7: None
Changes in v6: None
Changes in v5:
- Split binding doc's from driver changes. (Rob)
- Add eDP hotplug pinctrl property. (Heiko)

Changes in v4: None
Changes in v3: None
Changes in v2: None

 .../display/rockchip/analogix_dp-rockchip.txt  | 91 ++
 1 file changed, 91 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
new file mode 100644
index 000..04d99e3
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -0,0 +1,91 @@
+Rockchip RK3288 specific extensions to the Analogix Display Port
+
+
+Required properties:
+- compatible: "rockchip,rk3288-edp";
+
+- reg: physical base address of the controller and length
+
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+
+- clock-names: from common clock binding:
+  Required elements: "dp" "pclk"
+
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+
+- pinctrl-names: Names corresponding to the chip hotplug pinctrl states.
+- pinctrl-0: pin-control mode. should be <_hpd>
+
+- reset-names: Must include the name "dp"
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+
+- ports: there are 2 port nodes with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.
+Port 0: contained 2 endpoints, connecting to the output of vop.
+Port 1: contained 1 endpoint, connecting to the input of panel.
+
+For the below properties, please refer to Analogix DP binding document:
+ * Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
+- phys (required)
+- phy-names (required)
+- hpd-gpios (optional)
+---
+
+Example:
+   dp-controller: dp@ff97 {
+   compatible = "rockchip,rk3288-dp";
+   reg = <0xff97 0x4000>;
+   interrupts = ;
+   clocks = < SCLK_EDP>, < PCLK_EDP_CTRL>;
+   clock-names = "dp", "pclk";
+   phys = <_phy>;
+   phy-names = "dp";
+
+   rockchip,grf = <>;
+   resets = < 111>;
+   reset-names = "dp";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_hpd>;
+
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   edp_in: port@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   edp_in_vopb: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_edp>;
+   };
+   edp_in_vopl: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <_out_edp>;
+   };
+   };
+
+   edp_out: port@1 {
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   edp_out_panel: endpoint {
+   reg = <0>;
+   remote-endpoint = <_in_edp>
+   };
+   };
+   };
+   };
+
+   pinctrl {
+   edp {
+   edp_hpd: edp-hpd {
+   rockchip,pins = <7 11 RK_FUNC_2 
_pull_none>;
+   };
+   };
+   };
-- 
1.9.1


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

[PATCH v11 07/19] drm: rockchip: dp: add rockchip platform dp driver

[Yakir Yang]

Rockchip have three clocks for dp controller, we leave pclk_edp
to analogix_dp driver control, and keep the sclk_edp_24m and
sclk_edp in platform driver.

Signed-off-by: Yakir Yang 
Tested-by: Javier Martinez Canillas 
---
Changes in v11: None
Changes in v10:
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)

Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Remove the empty line at the end of document, and correct the endpoint
  numbers in the example DT node, and remove the regulator iomux setting
  in driver code while using the pinctl in devicetree instead. (Heiko)
- Add device type declared, cause the previous "platform device type
  support (v4 11/16)" already merge into (v5 02/14).
- Implement connector registration code. (Thierry)

Changes in v4:
- Remove some deprecated DT properties in rockchip dp document.

Changes in v3:
- Leave "sclk_edp_24m" to rockchip dp phy driver which name to "24m",
  and leave "sclk_edp" to analogix dp core driver which name to "dp",
  and leave "pclk_edp" to rockchip dp platform driver which name to
  "pclk". (Thierry & Heiko)
- Add devicetree binding document. (Heiko)
- Remove "rockchip,panel" DT property, take use of remote point to get panel
  node. (Heiko)
- Add the new function point dp_platdata->get_modes() init.

Changes in v2:
- Get panel node with remote-endpoint method, and create devicetree binding
  for driver. (Heiko)
- Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
  leave those clock to rockchip dp phy driver.

 drivers/gpu/drm/rockchip/Kconfig|   9 +
 drivers/gpu/drm/rockchip/Makefile   |   1 +
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 442 
 include/drm/bridge/analogix_dp.h|   1 +
 4 files changed, 453 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 35215f6..686cb49 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,3 +25,12 @@ config ROCKCHIP_DW_HDMI
  for the Synopsys DesignWare HDMI driver. If you want to
  enable HDMI on RK3288 based SoC, you should selet this
  option.
+
+config ROCKCHIP_ANALOGIX_DP
+   tristate "Rockchip specific extensions for Analogix DP driver"
+   depends on DRM_ROCKCHIP
+   select DRM_ANALOGIX_DP
+   help
+ This selects support for Rockchip SoC specific extensions
+ for the Analogix Core DP driver. If you want to enable DP
+ on RK3288 based SoC, you should selet this option.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index f3d8a19..8ad01fb 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -6,5 +6,6 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o 
rockchip_drm_fbdev.o \
rockchip_drm_gem.o
 
 obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
+obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
 
 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_drm_vop.o
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
new file mode 100644
index 000..2c82a9a
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -0,0 +1,442 @@
+/*
+ * Rockchip SoC DP (Display Port) interface driver.
+ *
+ * Copyright (C) Fuzhou Rockchip Electronics Co., Ltd.
+ * Author: Andy Yan 
+ * Yakir Yang 
+ * Jeff Chen 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define to_dp(nm)  container_of(nm, struct rockchip_dp_device, nm)
+
+/* dp grf register offset */
+#define GRF_SOC_CON60x025c
+#define GRF_EDP_LCD_SEL_MASKBIT(5)
+#define GRF_EDP_SEL_VOP_LIT BIT(5)
+#define GRF_EDP_SEL_VOP_BIG 0
+
+struct rockchip_dp_device {
+   struct drm_device*drm_dev;
+   struct device*dev;
+   struct drm_encoder   encoder;
+   struct drm_connector connector;
+   struct drm_display_mode  mode;
+
+   struct clk   *pclk;
+   struct regmap*grf;
+   struct reset_control *rst;
+
+   struct analogix_dp_plat_data plat_data;
+};
+
+static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
+{
+   reset_control_assert(dp->rst);
+   usleep_range(10, 20);
+  

linux-next: build failure after merge of the gpio tree

[Stephen Rothwell]

Hi Linus,

After merging the gpio tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

drivers/pinctrl/bcm/pinctrl-nsp-gpio.c: In function 'nsp_gpio_probe':
drivers/pinctrl/bcm/pinctrl-nsp-gpio.c:699:4: error: implicit declaration of 
function 'set_irq_flags' [-Werror=implicit-function-declaration]
set_irq_flags(irq, IRQF_VALID);
^
drivers/pinctrl/bcm/pinctrl-nsp-gpio.c:699:23: error: 'IRQF_VALID' undeclared 
(first use in this function)
set_irq_flags(irq, IRQF_VALID);
   ^

Caused by commit

  8bfcbbbcabe0 ("pinctrl: nsp: add gpio-a driver support for Broadcom NSP SoC")

set_irq_flags was removed before v4.3-rc2 ...

I have used the gpio tree from next-20151215 for today.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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 v11 06/19] ARM: dts: exynos/dp: remove some properties that deprecated by analogix_dp driver

[Yakir Yang]

After exynos_dp have been split the common IP code into analogix_dp driver,
the analogix_dp driver have deprecated some Samsung platform properties which
could be dynamically parsed from EDID/MODE/DPCD message, so this is an update
for Exynos DTS file for dp-controller.

Beside the backward compatibility is fully preserved, so there are no
bisectability break that make this change in a separate patch.

Signed-off-by: Yakir Yang 
Reviewed-by: Krzysztof Kozlowski 
Tested-by: Javier Martinez Canillas 
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6:
- Fix Peach Pit hpd property name error:
-   hpd-gpio = < 6 0>;
+   hpd-gpios = < 6 0>;

Changes in v5:
- Correct the misspell in commit message. (Krzysztof)

Changes in v4:
- Separate all DTS changes to a separate patch. (Krzysztof)

Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/exynos5250-arndale.dts  | 2 --
 arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 --
 arch/arm/boot/dts/exynos5250-snow-common.dtsi | 4 +---
 arch/arm/boot/dts/exynos5250-spring.dts   | 4 +---
 arch/arm/boot/dts/exynos5420-peach-pit.dts| 4 +---
 arch/arm/boot/dts/exynos5420-smdk5420.dts | 2 --
 arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 +---
 7 files changed, 4 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index c000532..b1790cf 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -124,8 +124,6 @@
  {
status = "okay";
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 0f5dcd4..f30c2db 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -80,8 +80,6 @@
 
  {
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi 
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index 5cb33ba..b96624b 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -236,12 +236,10 @@
pinctrl-names = "default";
pinctrl-0 = <_hpd>;
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <2>;
-   samsung,hpd-gpio = < 7 GPIO_ACTIVE_HIGH>;
+   hpd-gpios = < 7 GPIO_ACTIVE_HIGH>;
 
ports {
port@0 {
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts 
b/arch/arm/boot/dts/exynos5250-spring.dts
index c1edd6d..91881d7 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -74,12 +74,10 @@
pinctrl-names = "default";
pinctrl-0 = <_hpd_gpio>;
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <1>;
-   samsung,hpd-gpio = < 0 GPIO_ACTIVE_HIGH>;
+   hpd-gpios = < 0 GPIO_ACTIVE_HIGH>;
 };
 
  {
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 35cfb07..2f37c87 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -148,12 +148,10 @@
pinctrl-names = "default";
pinctrl-0 = <_hpd_gpio>;
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x06>;
samsung,lane-count = <2>;
-   samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
+   hpd-gpios = < 6 GPIO_ACTIVE_HIGH>;
 
ports {
port@0 {
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index ac35aef..f67344f 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -93,8 +93,6 @@
pinctrl-names = "default";
pinctrl-0 = <_hpd>;
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 7b018e4..363c95f 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ 

[PATCH v11 05/19] dt-bindings: add document for analogix display port driver

[Yakir Yang]

Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt

Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.

Signed-off-by: Yakir Yang 
Acked-by: Rob Herring 
Tested-by: Javier Martinez Canillas 
---
Changes in v11: None
Changes in v10:
- Add the ack from Rob Herring

Changes in v9: None
Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Split all DTS changes, and provide backward compatibility. Mark old
  properties as deprecated but still support them. (Krzysztof)
- Update "analogix,hpd-gpio" to "hpd-gpios" prop name. (Rob)
- Deprecated some properties which could parsed from Edid/Mode/DPCD. (Thierry)
"analogix,color-space" & "analogix,color-depth"   &
"analogix,link-rate"   & "analogix,lane-count"&
"analogix,ycbcr-coeff" & "analogix,dynamic-range" &
"vsync-active-high"& "hsync-active-high"  & "interlaces"

Changes in v3:
- Add devicetree binding documents. (Heiko)
- Remove sync pol & colorimetry properies from the new analogix dp driver
  devicetree binding. (Thierry)
- Update the exist exynos dtsi file with the latest DP DT properies.

Changes in v2: None

 .../bindings/display/bridge/analogix_dp.txt| 50 +
 .../bindings/display/exynos/exynos_dp.txt  | 65 --
 2 files changed, 72 insertions(+), 43 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/analogix_dp.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt 
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
new file mode 100644
index 000..7659a7a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -0,0 +1,50 @@
+Analogix Display Port bridge bindings
+
+Required properties for dp-controller:
+   -compatible:
+   platform specific such as:
+* "samsung,exynos5-dp"
+* "rockchip,rk3288-dp"
+   -reg:
+   physical base address of the controller and length
+   of memory mapped region.
+   -interrupts:
+   interrupt combiner values.
+   -clocks:
+   from common clock binding: handle to dp clock.
+   -clock-names:
+   from common clock binding: Shall be "dp".
+   -interrupt-parent:
+   phandle to Interrupt combiner node.
+   -phys:
+   from general PHY binding: the phandle for the PHY device.
+   -phy-names:
+   from general PHY binding: Should be "dp".
+
+Optional properties for dp-controller:
+   -hpd-gpios:
+   Hotplug detect GPIO.
+   Indicates which GPIO should be used for hotplug detection
+   -port@[X]: SoC specific port nodes with endpoint definitions as defined
+   in Documentation/devicetree/bindings/media/video-interfaces.txt,
+   please refer to the SoC specific binding document:
+   * Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+   * 
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
+
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+---
+
+Example:
+
+   dp-controller {
+   compatible = "samsung,exynos5-dp";
+   reg = <0x145b 0x1>;
+   interrupts = <10 3>;
+   interrupt-parent = <>;
+   clocks = < 342>;
+   clock-names = "dp";
+
+   phys = <_phy>;
+   phy-names = "dp";
+   };
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt 
b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index 64693f2..9905081 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -31,45 +31,31 @@ Required properties for dp-controller:
from general PHY binding: the phandle for the PHY device.
-phy-names:
from general PHY binding: Should be "dp".
-   -samsung,color-space:
-   input video data format.
-   COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
-   -samsung,dynamic-range:
-   dynamic range for input video data.
-   VESA = 0, CEA = 1
-   -samsung,ycbcr-coeff:
-   YCbCr co-efficients for input video.
-   COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
-   -samsung,color-depth:
-   number of bits per colour component.
-   COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
-   -samsung,link-rate:
- 

[PATCH v11 04/19] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

[Yakir Yang]

Both hsync/vsync polarity and interlace mode can be parsed from
drm display mode, and dynamic_range and ycbcr_coeff can be judge
by the video code.

But presumably Exynos still relies on the DT properties, so take
good use of mode_fixup() in to achieve the compatibility hacks.

Signed-off-by: Yakir Yang 
Reviewed-by: Krzysztof Kozlowski 
Tested-by: Javier Martinez Canillas 
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
  compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
  to avoid -EOVERFLOW error (Krzysztof)

Changes in v6: None
Changes in v5:
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
  to get the backword timing values. Krzysztof suggest me that driver could use
  the "of_property_read_bool" to get backword timing values, but that interfacs
  would modify the original drm_display_mode timing directly (whether those
  properties exists or not).

Changes in v4:
- Provide backword compatibility with samsung. (Krzysztof)

Changes in v3:
- Dynamic parse video timing info from struct drm_display_mode and
  struct drm_display_info. (Thierry)

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 148 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   2 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  14 +-
 3 files changed, 103 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 6f899cd..a0d97cb 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -890,8 +890,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
return;
}
 
-   ret = analogix_dp_set_link_train(dp, dp->video_info->lane_count,
-dp->video_info->link_rate);
+   ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
+dp->video_info.link_rate);
if (ret) {
dev_err(dp->dev, "unable to do link train\n");
return;
@@ -1032,6 +1032,85 @@ static void analogix_dp_bridge_disable(struct drm_bridge 
*bridge)
dp->dpms_mode = DRM_MODE_DPMS_OFF;
 }
 
+static void analogix_dp_bridge_mode_set(struct drm_bridge *bridge,
+   struct drm_display_mode *orig_mode,
+   struct drm_display_mode *mode)
+{
+   struct analogix_dp_device *dp = bridge->driver_private;
+   struct drm_display_info *display_info = >connector->display_info;
+   struct video_info *video = >video_info;
+   struct device_node *dp_node = dp->dev->of_node;
+   int vic;
+
+   /* Input video interlaces & hsync pol & vsync pol */
+   video->interlaced = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
+   video->v_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NVSYNC);
+   video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
+
+   /* Input video dynamic_range & colorimetry */
+   vic = drm_match_cea_mode(mode);
+   if ((vic == 6) || (vic == 7) || (vic == 21) || (vic == 22) ||
+   (vic == 2) || (vic == 3) || (vic == 17) || (vic == 18)) {
+   video->dynamic_range = CEA;
+   video->ycbcr_coeff = COLOR_YCBCR601;
+   } else if (vic) {
+   video->dynamic_range = CEA;
+   video->ycbcr_coeff = COLOR_YCBCR709;
+   } else {
+   video->dynamic_range = VESA;
+   video->ycbcr_coeff = COLOR_YCBCR709;
+   }
+
+   /* Input vide bpc and color_formats */
+   switch (display_info->bpc) {
+   case 12:
+   video->color_depth = COLOR_12;
+   break;
+   case 10:
+   video->color_depth = COLOR_10;
+   break;
+   case 8:
+   video->color_depth = COLOR_8;
+   break;
+   case 6:
+   video->color_depth = COLOR_6;
+   break;
+   default:
+   video->color_depth = COLOR_8;
+   break;
+   }
+   if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB444)
+   video->color_space = COLOR_YCBCR444;
+   else if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB422)
+   video->color_space = COLOR_YCBCR422;
+   else if (display_info->color_formats & DRM_COLOR_FORMAT_RGB444)
+   video->color_space = COLOR_RGB;
+   else
+   video->color_space = COLOR_RGB;
+
+   /*
+* NOTE: those property parsing code is used for providing backward
+* compatibility for samsung platform.
+* Due to we used the "of_property_read_u32" interfaces, when this
+* property isn't present, the "video_info" can keep the 

Re: [PATCH] net: emac: emac gigabit ethernet controller driver

[Timur Tabi]

David Miller wrote:

I think you did something much worse.  You quoted the entire huge
patch which is entirely inappropriate given the feedback you were
trying to give.


Sorry about that.  I usually do trim it, but I got tired and forgot 
before I hit send.


--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v11 03/19] drm: bridge: analogix/dp: remove duplicate configuration of link rate and link count

[Yakir Yang]

link_rate and lane_count already configured in analogix_dp_set_link_train(),
so we don't need to config those repeatly after training finished, just
remove them out.

Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7Gbps, 5.4Gbps}.

Signed-off-by: Yakir Yang 
Tested-by: Javier Martinez Canillas 
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Update commit message more readable. (Jingoo)
- Adjust the order from 05 to 04

Changes in v3:
- The link_rate and lane_count shouldn't config to the DT property value
  directly, but we can take those as hardware limite. For example, RK3288
  only support 4 physical lanes of 2.7/1.62 Gbps/lane, so DT property would
  like "link-rate = 0x0a" "lane-count = 4". (Thierry)

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 8 
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 5 +++--
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 4a05c2b..6f899cd 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -624,6 +624,8 @@ static void analogix_dp_get_max_rx_bandwidth(struct 
analogix_dp_device *dp,
/*
 * For DP rev.1.1, Maximum link rate of Main Link lanes
 * 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps
+* For DP rev.1.2, Maximum link rate of Main Link lanes
+* 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps, 0x14 = 5.4Gbps
 */
analogix_dp_read_byte_from_dpcd(dp, DP_MAX_LINK_RATE, );
*bandwidth = data;
@@ -657,7 +659,8 @@ static void analogix_dp_init_training(struct 
analogix_dp_device *dp,
analogix_dp_get_max_rx_lane_count(dp, >link_train.lane_count);
 
if ((dp->link_train.link_rate != LINK_RATE_1_62GBPS) &&
-   (dp->link_train.link_rate != LINK_RATE_2_70GBPS)) {
+   (dp->link_train.link_rate != LINK_RATE_2_70GBPS) &&
+   (dp->link_train.link_rate != LINK_RATE_5_40GBPS)) {
dev_err(dp->dev, "Rx Max Link Rate is abnormal :%x !\n",
dp->link_train.link_rate);
dp->link_train.link_rate = LINK_RATE_1_62GBPS;
@@ -898,9 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
analogix_dp_enable_rx_to_enhanced_mode(dp, 1);
analogix_dp_enable_enhanced_mode(dp, 1);
 
-   analogix_dp_set_lane_count(dp, dp->video_info->lane_count);
-   analogix_dp_set_link_bandwidth(dp, dp->video_info->link_rate);
-
analogix_dp_init_video(dp);
ret = analogix_dp_config_video(dp);
if (ret)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 8e84208..57aa4b0d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -21,8 +21,9 @@
 #define MAX_EQ_LOOP5
 
 enum link_rate_type {
-   LINK_RATE_1_62GBPS = 0x06,
-   LINK_RATE_2_70GBPS = 0x0a
+   LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
+   LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
+   LINK_RATE_5_40GBPS = DP_LINK_BW_5_4,
 };
 
 enum link_lane_count_type {
-- 
1.9.1


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

Re: [PATCH RFC] memory-hotplug: add automatic onlining policy for the newly added memory

[Xishi Qiu]

On 2015/12/16 2:05, Vitaly Kuznetsov wrote:

> Currently, all newly added memory blocks remain in 'offline' state unless
> someone onlines them, some linux distributions carry special udev rules
> like:
> 
> SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline", 
> ATTR{state}="online"
> 
> to make this happen automatically. This is not a great solution for virtual
> machines where memory hotplug is being used to address high memory pressure
> situations as such onlining is slow and a userspace process doing this
> (udev) has a chance of being killed by the OOM killer as it will probably
> require to allocate some memory.
> 
> Introduce default policy for the newly added memory blocks in
> /sys/devices/system/memory/hotplug_autoonline file with two possible
> values: "offline" (the default) which preserves the current behavior and
> "online" which causes all newly added memory blocks to go online as
> soon as they're added.
> 
> Cc: Jonathan Corbet 
> Cc: Greg Kroah-Hartman 
> Cc: Daniel Kiper 
> Cc: Dan Williams 
> Cc: Tang Chen 
> Cc: David Vrabel 
> Cc: David Rientjes 
> Cc: Andrew Morton 
> Cc: Naoya Horiguchi 
> Cc: Gu Zheng 
> Cc: Xishi Qiu 
> Cc: Mel Gorman 
> Cc: "K. Y. Srinivasan" 
> Signed-off-by: Vitaly Kuznetsov 
> ---
> - I was able to find previous attempts to fix the issue, e.g.:
>   http://marc.info/?l=linux-kernel=137425951924598=2
>   http://marc.info/?l=linux-acpi=127186488905382
>   but I'm not completely sure why it didn't work out and the solution
>   I suggest is not 'smart enough', thus 'RFC'.

+ CC: 
yanxiaof...@inspur.com
liuchangsh...@inspur.com

Hi Vitaly,

Why not use udev rule? I think it can online pages automatically.

Thanks,
Xishi Qiu

--
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 v11 02/19] drm: bridge: analogix/dp: fix some obvious code style

[Yakir Yang]

Fix some obvious alignment problems, like alignment and line
over 80 characters problems, make this easy to be maintained
later.

Signed-off-by: Yakir Yang 
Reviewed-by: Krzysztof Kozlowski 
Tested-by: Javier Martinez Canillas 
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Resequence this patch after analogix_dp driver have been split
  from exynos_dp code, and rephrase reasonable commit message, and
  remove some controversial style (Krzysztof)
-   analogix_dp_write_byte_to_dpcd(
-   dp, DP_TEST_RESPONSE,
+   analogix_dp_write_byte_to_dpcd(dp,
+   DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);

Changes in v4: None
Changes in v3: None
Changes in v2:
- Improved commit message more readable, and avoid using some
  uncommon style like bellow: (Joe Preches)
-  retval = exynos_dp_read_bytes_from_i2c(...
  ...);
+  retval =
+  exynos_dp_read_bytes_from_i2c(..);

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 129 ++---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  72 ++--
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 124 ++--
 3 files changed, 163 insertions(+), 162 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index fb8bda8..4a05c2b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -61,7 +61,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
*dp)
 
while (analogix_dp_get_plug_in_status(dp) != 0) {
timeout_loop++;
-   if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
+   if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
dev_err(dp->dev, "failed to get hpd plug status\n");
return -ETIMEDOUT;
}
@@ -98,8 +98,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)
 
/* Read Extension Flag, Number of 128-byte EDID extension blocks */
retval = analogix_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
-   EDID_EXTENSION_FLAG,
-   _block);
+   EDID_EXTENSION_FLAG,
+   _block);
if (retval)
return retval;
 
@@ -107,7 +107,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)
dev_dbg(dp->dev, "EDID data includes a single extension!\n");
 
/* Read EDID data */
-   retval = analogix_dp_read_bytes_from_i2c(dp, 
I2C_EDID_DEVICE_ADDR,
+   retval = analogix_dp_read_bytes_from_i2c(dp,
+   I2C_EDID_DEVICE_ADDR,
EDID_HEADER_PATTERN,
EDID_BLOCK_LENGTH,
[EDID_HEADER_PATTERN]);
@@ -138,7 +139,7 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)
}
 
analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
-   _vector);
+   _vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
analogix_dp_write_byte_to_dpcd(dp,
DP_TEST_EDID_CHECKSUM,
@@ -152,10 +153,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)
 
/* Read EDID data */
retval = analogix_dp_read_bytes_from_i2c(dp,
-   I2C_EDID_DEVICE_ADDR,
-   EDID_HEADER_PATTERN,
-   EDID_BLOCK_LENGTH,
-   [EDID_HEADER_PATTERN]);
+   I2C_EDID_DEVICE_ADDR, EDID_HEADER_PATTERN,
+   EDID_BLOCK_LENGTH, [EDID_HEADER_PATTERN]);
if (retval != 0) {
dev_err(dp->dev, "EDID Read failed!\n");
return -EIO;
@@ -166,16 +165,13 @@ static int analogix_dp_read_edid(struct 
analogix_dp_device *dp)
return -EIO;
}
 
-   analogix_dp_read_byte_from_dpcd(dp,
-   DP_TEST_REQUEST,
-   _vector);
+   analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
+   _vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
analogix_dp_write_byte_to_dpcd(dp,
-   DP_TEST_EDID_CHECKSUM,
-   

[PATCH v11 0/19] Add Analogix Core Display Port Driver

[Yakir Yang]

Hi all,

   The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
share the same IP, so a lot of parts can be re-used. I split the common
code into bridge directory, then rk3288 and exynos only need to keep
some platform code. Cause I can't find the exact IP name of exynos dp
controller, so I decide to name dp core driver with "analogix" which I
find in rk3288 eDP TRM

But  there are still three light registers setting differents bewteen
exynos and rk3288.
1. RK3288 have five special pll resigters which not indicata in exynos
   dp controller.
2. The address of DP_PHY_PD(dp phy power manager register) are different
   between rk3288 and exynos.
3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
   register).

This series have been well tested on Rockchip platform with eDP panel on
Jerry Chromebook and Display Port Monitor on RK3288 board. Also I have
tested on Samsung Snow and Peach Pit Chromebooks, and thanks to Javier@Samsung
help to retest the whole series on Samsung Exynos5800 Peach Pi Chromebook,
glad to say that things works rightlly.

Thanks,
- Yakir


Changes in v11:
- Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
- Correct the title of this rockchip dp phy document(Rob)
- Add the ack from Rob Herring
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
- Add the ack from Rob Herring
- Revert parts of Gustavo Padovan's changes in commit:
drm/exynos: do not start enabling DP at bind() phase
  Add dp phy poweron function in bind time.
- Move the panel prepare from get_modes time to bind time, and move
  the panel unprepare from bridge->disable to unbind time. (Heiko)

Changes in v10:
- Add the ack from Rob Herring
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)
- Add the ack from Rob Herring
- Fix the wrong macro value of GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK
BIT(4) -> BIT(20)
- Remove the surplus "plat_data" check. (Heiko)
-   switch (dp->plat_data && dp->plat_data->dev_type) {
+   switch (dp->plat_data->dev_type) {

Changes in v9:
- Document more details for 'ports' property.
- Removed the unused the variable "res" in probe function. (Heiko)
- Removed the unused head file.

Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)
- Modify the commit subject name. (Heiko)
- Fix the mixed spacers on macro definitions. (Heiko)
- Remove the unnecessary empty line after clk_prepare_enable. (Heiko)
- Remove the specific address in the example node name. (Heiko)

Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
  compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
  to avoid -EOVERFLOW error (Krzysztof)
- Simply the commit message. (Kishon)
- Symmetrical enable/disbale the phy clock and power. (Kishon)
- Simplify the commit message. (Kishon)

Changes in v6:
- Fix the Kconfig recursive dependency (Javier)
- Fix Peach Pit hpd property name error:
-   hpd-gpio = < 6 0>;
+   hpd-gpios = < 6 0>;

Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
  the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
  attch function. Cause once platform failed at attach, core driver should
  still failed, so no need to init connector before platform attached 
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
  patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)
- Resequence this patch after analogix_dp driver have been split
  from exynos_dp code, and rephrase reasonable commit message, and
  remove some controversial style (Krzysztof)
-   analogix_dp_write_byte_to_dpcd(
-   dp, DP_TEST_RESPONSE,
+   analogix_dp_write_byte_to_dpcd(dp,
+   DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
  to get the backword timing values. Krzysztof suggest me that driver could use
  the "of_property_read_bool" to get backword timing values, but that interfacs
  would modify the original drm_display_mode timing directly (whether those
  properties exists or not).
- Correct the misspell in commit message. (Krzysztof)
- Remove the empty line at the end of document, and correct the endpoint
  numbers in the example DT node, and remove the regulator iomux setting
  in driver code while using the pinctl in devicetree instead. (Heiko)
- Add device type declared, cause the previous "platform device type
  support (v4 11/16)" already merge into (v5 02/14).
- Implement connector registration code. (Thierry)
- Split 

Re: [PATCH] mm: mempool: Factor out mempool_refill()

[Zhi Wang]

Hi Johannes:
Thanks for the reply. In the end of the mempool_resize(), it will 
call the mempool_refill() to do the rest of the work. So this is not one 
of the "no-caller" case. If you insist this is a "no-caller" case, 
perhaps I should change it to a "static" function without exposing a new 
interface?


Personally I think mempool_refill() should be one of the typical 
interfaces in an implementation of a mempool. Currently the mempool will 
not grow only if pool->min_nr > new_min_nr.


So when user wants to refill the mempool immediately, not resize a 
mempool, in the current implementation, it has to do 2x 
mempool_resize(). First one is mempool_resize(pool->min_nr - 1), second 
one is mempool_resize(new_min_nr). So the refill action would truly 
happen. This is ugly and not convenient.


On 12/16/15 05:26, Johannes Weiner wrote:

On Mon, Dec 14, 2015 at 11:09:43AM +, Wang, Zhi A wrote:

This patch factors out mempool_refill() from mempool_resize(). It's reasonable
that the mempool user wants to refill the pool immdiately when it has chance
e.g. inside a sleepible context, so that next time in the IRQ context the pool
would have much more available elements to allocate.

After the refactor, mempool_refill() can also executes with mempool_resize()
/mempool_alloc/mempool_free() or another mempool_refill().

Signed-off-by: Zhi Wang 


Who is going to call that function? Adding a new interace usually
comes with a user, or as part of a series that adds users.


--
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 7/8] f2fs: introduce new option for controlling data flush

[Chao Yu]

Hi Jaegeuk,

> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Wednesday, December 16, 2015 10:49 AM
> To: Chao Yu
> Cc: linux-f2fs-de...@lists.sourceforge.net; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 7/8] f2fs: introduce new option for controlling data flush
> 
> Hi Chao,
> 
> On Wed, Dec 16, 2015 at 10:38:27AM +0800, Chao Yu wrote:
> 
> ...
> 
> > > > +++ b/fs/f2fs/super.c
> > > > @@ -67,6 +67,7 @@ enum {
> > > > Opt_extent_cache,
> > > > Opt_noextent_cache,
> > > > Opt_noinline_data,
> > > > +   Opt_data_flush,
> > >
> > > Need Opt_nodata_flush too.
> >
> > We need this unless we set data_flush as a default option. Is that right?
> 
> I meant both of them.

Yeah, I know that. But the point I meant was:
Normally we can detect user's mount option by test_opt(DATA_FLUSH), but if
data_flush option was set as a default option in f2fs, we need to introduce
nodata_flush to indicate whether user want to disable it or not, because we
can't disable data_flush option by mount without it since f2fs will set
data_flush by itself.

So it seems nodata_flush is redundant unless data_flush is set by default.

How do you think of it?

Thanks,

> 
> Thanks,
> 
> >
> > Thanks,
> >
> > >
> > > Thanks,
> > >
> > > > Opt_nodiscard,
> > > > Opt_err,
> > > >  };
> > > > @@ -92,6 +93,7 @@ static match_table_t f2fs_tokens = {
> > > > {Opt_extent_cache, "extent_cache"},
> > > > {Opt_noextent_cache, "noextent_cache"},
> > > > {Opt_noinline_data, "noinline_data"},
> > > > +   {Opt_data_flush, "data_flush"},
> > > > {Opt_nodiscard, "nodiscard"},
> > > > {Opt_err, NULL},
> > > >  };
> > > > @@ -411,6 +413,9 @@ static int parse_options(struct super_block *sb, 
> > > > char *options)
> > > > case Opt_noinline_data:
> > > > clear_opt(sbi, INLINE_DATA);
> > > > break;
> > > > +   case Opt_data_flush:
> > > > +   clear_opt(sbi, DATA_FLUSH);
> > > > +   break;
> > > > default:
> > > > f2fs_msg(sb, KERN_ERR,
> > > > "Unrecognized mount option \"%s\" or 
> > > > missing value",
> > > > @@ -694,6 +699,8 @@ static int f2fs_show_options(struct seq_file *seq, 
> > > > struct dentry *root)
> > > > seq_puts(seq, ",extent_cache");
> > > > else
> > > > seq_puts(seq, ",noextent_cache");
> > > > +   if (test_opt(sbi, DATA_FLUSH))
> > > > +   seq_puts(seq, ",data_flush");
> > > > seq_printf(seq, ",active_logs=%u", sbi->active_logs);
> > > >
> > > > return 0;
> > > > --
> > > > 2.6.3
> > > >

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

[PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency

[Baolin Wang]

>From the dm-crypt performance report, we found it shows low efficiency
with crypto engine for some mode (like ecb or xts mode). Because in dm
crypt, it will map the IO data buffer with scatterlist, and send the
scatterlist of one bio to the encryption engine, if send more scatterlists
with bigger size at one time, that helps the engine palys best performance,
which means a high encryption speed. 

But now the dm-crypt only map one segment (always one sector) of one bio
with one scatterlist to the crypto engine at one time. which is more
time-consuming and ineffective for the crypto engine. Especially for some
modes which don't need different IV for each sector, we can map the whole
bio with multiple scatterlists to improve the engine performance.

But this optimization is not support some ciphers and IV modes which should
do sector by sector and need different IV for each sector.

Change since v1:
 - Introduce one different IV mode.
 - Change the conditions for bulk mode.

Baolin Wang (2):
  block: Export the __blk_bios_map_sg() to map one bio
  md: dm-crypt: Introduce the bulk IV mode for bulk crypto

 block/blk-merge.c  |7 +-
 drivers/md/dm-crypt.c  |  333 +++-
 include/linux/blkdev.h |3 +
 3 files changed, 334 insertions(+), 9 deletions(-)

-- 
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/7] mm: memcontrol: charge swap to cgroup2

[Kamezawa Hiroyuki]

On 2015/12/15 23:50, Johannes Weiner wrote:

On Tue, Dec 15, 2015 at 12:22:41PM +0900, Kamezawa Hiroyuki wrote:

On 2015/12/15 4:42, Vladimir Davydov wrote:

Anyway, if you don't trust a container you'd better set the hard memory
limit so that it can't hurt others no matter what it runs and how it
tweaks its sub-tree knobs.


Limiting swap can easily cause "OOM-Killer even while there are available swap"
with easy mistake. Can't you add "swap excess" switch to sysctl to allow global
memory reclaim can ignore swap limitation ?


That never worked with a combined memory+swap limit, either. How could
it? The parent might swap you out under pressure, but simply touching
a few of your anon pages causes them to get swapped back in, thrashing
with whatever the parent was trying to do. Your ability to swap it out
is simply no protection against a group touching its pages.

Allowing the parent to exceed swap with separate counters makes even
less sense, because every page swapped out frees up a page of memory
that the child can reuse. For every swap page that exceeds the limit,
the child gets a free memory page! The child doesn't even have to
cause swapin, it can just steal whatever the parent tried to free up,
and meanwhile its combined memory & swap footprint explodes.


Sure.


The answer is and always should have been: don't overcommit untrusted
cgroups. Think of swap as a resource you distribute, not as breathing
room for the parents to rely on. Because it can't and could never.


ok, don't overcommmit.


And the new separate swap counter makes this explicit.


Hmm, my requests are
 - set the same capabilities as mlock() to set swap.limit=0
 - swap-full notification via vmpressure or something mechanism.
 - OOM-Killer's available memory calculation may be corrupted, please check.
 - force swap-in at reducing swap.limit

Thanks,
-Kame


--
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] md: dm-crypt: Introduce the bulk IV mode for bulk crypto

[Baolin Wang]

In now dm-crypt code, it is ineffective to map one segment (always one
sector) of one bio with just only one scatterlist at one time for hardware
crypto engine. Especially for some encryption mode (like ecb or xts mode)
cooperating with the crypto engine, they just need one initial IV or null
IV instead of different IV for each sector. In this situation We can consider
to use multiple scatterlists to map the whole bio and send all scatterlists
of one bio to crypto engine to encrypt or decrypt, which can improve the
hardware engine's efficiency.

With this optimization, On my test setup (beaglebone black board) using 64KB
I/Os on an eMMC storage device I saw about 60% improvement in throughput for
encrypted writes, and about 100% improvement for encrypted reads. But this
is not fit for other modes which need different IV for each sector.

Signed-off-by: Baolin Wang 
---
 drivers/md/dm-crypt.c |  333 -
 1 file changed, 327 insertions(+), 6 deletions(-)

diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 917d47e..dc2e5e6 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -32,6 +32,7 @@
 #include 
 
 #define DM_MSG_PREFIX "crypt"
+#define DM_MAX_SG_LIST 1024
 
 /*
  * context holding the current state of a multi-part conversion
@@ -68,6 +69,8 @@ struct dm_crypt_request {
struct convert_context *ctx;
struct scatterlist sg_in;
struct scatterlist sg_out;
+   struct sg_table sgt_in;
+   struct sg_table sgt_out;
sector_t iv_sector;
 };
 
@@ -140,6 +143,7 @@ struct crypt_config {
char *cipher;
char *cipher_string;
 
+   int bulk_crypto;
struct crypt_iv_operations *iv_gen_ops;
union {
struct iv_essiv_private essiv;
@@ -238,6 +242,9 @@ static struct crypto_ablkcipher *any_tfm(struct 
crypt_config *cc)
  *
  * plumb: unimplemented, see:
  * http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/454
+ *
+ * bulk: the initial vector is the 64-bit little-endian version of the sector
+ *  number, which is used as just one initial IV for one bulk data.
  */
 
 static int crypt_iv_plain_gen(struct crypt_config *cc, u8 *iv,
@@ -755,6 +762,15 @@ static int crypt_iv_tcw_post(struct crypt_config *cc, u8 
*iv,
return r;
 }
 
+static int crypt_iv_bulk_gen(struct crypt_config *cc, u8 *iv,
+struct dm_crypt_request *dmreq)
+{
+   memset(iv, 0, cc->iv_size);
+   *(__le64 *)iv = cpu_to_le64(dmreq->iv_sector);
+
+   return 0;
+}
+
 static struct crypt_iv_operations crypt_iv_plain_ops = {
.generator = crypt_iv_plain_gen
 };
@@ -799,6 +815,10 @@ static struct crypt_iv_operations crypt_iv_tcw_ops = {
.post  = crypt_iv_tcw_post
 };
 
+static struct crypt_iv_operations crypt_iv_bulk_ops = {
+   .generator = crypt_iv_bulk_gen
+};
+
 static void crypt_convert_init(struct crypt_config *cc,
   struct convert_context *ctx,
   struct bio *bio_out, struct bio *bio_in,
@@ -833,6 +853,11 @@ static u8 *iv_of_dmreq(struct crypt_config *cc,
crypto_ablkcipher_alignmask(any_tfm(cc)) + 1);
 }
 
+static int crypt_is_bulk_mode(struct crypt_config *cc)
+{
+   return cc->bulk_crypto;
+}
+
 static int crypt_convert_block(struct crypt_config *cc,
   struct convert_context *ctx,
   struct ablkcipher_request *req)
@@ -881,24 +906,40 @@ static int crypt_convert_block(struct crypt_config *cc,
 
 static void kcryptd_async_done(struct crypto_async_request *async_req,
   int error);
+static void kcryptd_async_all_done(struct crypto_async_request *async_req,
+  int error);
 
 static void crypt_alloc_req(struct crypt_config *cc,
struct convert_context *ctx)
 {
unsigned key_index = ctx->cc_sector & (cc->tfms_count - 1);
+   struct dm_crypt_request *dmreq;
 
if (!ctx->req)
ctx->req = mempool_alloc(cc->req_pool, GFP_NOIO);
 
+   dmreq = dmreq_of_req(cc, ctx->req);
+   dmreq->sgt_in.orig_nents = 0;
+   dmreq->sgt_out.orig_nents = 0;
+
ablkcipher_request_set_tfm(ctx->req, cc->tfms[key_index]);
 
/*
 * Use REQ_MAY_BACKLOG so a cipher driver internally backlogs
 * requests if driver request queue is full.
 */
-   ablkcipher_request_set_callback(ctx->req,
-   CRYPTO_TFM_REQ_MAY_BACKLOG | CRYPTO_TFM_REQ_MAY_SLEEP,
-   kcryptd_async_done, dmreq_of_req(cc, ctx->req));
+   if (crypt_is_bulk_mode(cc))
+   ablkcipher_request_set_callback(ctx->req,
+   CRYPTO_TFM_REQ_MAY_BACKLOG
+   | CRYPTO_TFM_REQ_MAY_SLEEP,
+   kcryptd_async_all_done,
+

[PATCH v2 1/2] block: Export the __blk_bios_map_sg() to map one bio

[Baolin Wang]

In dm-crypt, it need to map one bio to scatterlist for improving the
encryption efficiency. Thus this patch exports the __blk_bios_map_sg()
function to map one bio with scatterlists.

Signed-off-by: Baolin Wang 
---
 block/blk-merge.c  |7 ---
 include/linux/blkdev.h |3 +++
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/block/blk-merge.c b/block/blk-merge.c
index de5716d8..09cc7c4 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -331,9 +331,9 @@ new_segment:
*bvprv = *bvec;
 }
 
-static int __blk_bios_map_sg(struct request_queue *q, struct bio *bio,
-struct scatterlist *sglist,
-struct scatterlist **sg)
+int __blk_bios_map_sg(struct request_queue *q, struct bio *bio,
+ struct scatterlist *sglist,
+ struct scatterlist **sg)
 {
struct bio_vec bvec, bvprv = { NULL };
struct bvec_iter iter;
@@ -372,6 +372,7 @@ single_segment:
 
return nsegs;
 }
+EXPORT_SYMBOL(__blk_bios_map_sg);
 
 /*
  * map a request to scatterlist, return number of sg entries setup. Caller
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 3fe27f8..dd8d10f 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1004,6 +1004,9 @@ extern void blk_queue_flush_queueable(struct 
request_queue *q, bool queueable);
 extern struct backing_dev_info *blk_get_backing_dev_info(struct block_device 
*bdev);
 
 extern int blk_rq_map_sg(struct request_queue *, struct request *, struct 
scatterlist *);
+extern int __blk_bios_map_sg(struct request_queue *q, struct bio *bio,
+struct scatterlist *sglist,
+struct scatterlist **sg);
 extern void blk_dump_rq_flags(struct request *, char *);
 extern long nr_blockdev_pages(void);
 
-- 
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] net: emac: emac gigabit ethernet controller driver

[David Miller]

From: Timur Tabi 
Date: Tue, 15 Dec 2015 18:15:50 -0600

> You forgot to add "[v2]" to the subject line of this email.

I think you did something much worse.  You quoted the entire huge
patch which is entirely inappropriate given the feedback you were
trying to give.

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: [PATCH] SUNRPC: restore fair scheduling to priority queues.

[NeilBrown]

On Wed, Dec 16 2015, Trond Myklebust wrote:

> On Tue, Dec 15, 2015 at 6:44 PM, NeilBrown  wrote:
>>
>> Commit: c05eecf63610 ("SUNRPC: Don't allow low priority tasks to pre-empt 
>> higher priority ones")
>>
>> removed the 'fair scheduling' feature from SUNRPC priority queues.
>> This feature caused problems for some queues (send queue and session slot 
>> queue)
>> but is still needed for others, particularly the tcp slot queue.
>>
>> Without fairness, reads (priority 1) can starve background writes
>> (priority 0) so a streaming read can cause writeback to block
>> indefinitely.  This is not easy to measure with default settings as
>> the current slot table size is much larger than the read-ahead size.
>> However if the slot-table size is reduced (seen when backporting to
>> older kernels with a limited size) the problem is easily demonstrated.
>>
>> This patch conditionally restores fair scheduling.  It is now the
>> default unless rpc_sleep_on_priority() is called directly.  Then the
>> queue switches to strict priority observance.
>>
>> As that function is called for both the send queue and the session
>> slot queue and not for any others, this has exactly the desired
>> effect.
>>
>> The "count" field that was removed by the previous patch is restored.
>> A value for '255' means "strict priority queuing, no fair queuing".
>> Any other value is a could of owners to be processed before switching
>> to a different priority level, just like before.
>>
>> Signed-off-by: NeilBrown 
>> ---
>>
>> It is quite possible that you won't like the overloading of
>> rpc_sleep_on_priority() to disable fair-scheduling and would prefer an
>> extra arg to rpc_init_priority_wait_queue().  I can do it that way if
>> you like.
>> NeilBrown
>>
>>
>>  include/linux/sunrpc/sched.h |  1 +
>>  net/sunrpc/sched.c   | 12 +---
>>  2 files changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/linux/sunrpc/sched.h b/include/linux/sunrpc/sched.h
>> index d703f0ef37d8..985efe8d7e26 100644
>> --- a/include/linux/sunrpc/sched.h
>> +++ b/include/linux/sunrpc/sched.h
>> @@ -184,6 +184,7 @@ struct rpc_wait_queue {
>> pid_t   owner;  /* process id of 
>> last task serviced */
>> unsigned char   maxpriority;/* maximum priority 
>> (0 if queue is not a priority queue) */
>> unsigned char   priority;   /* current priority 
>> */
>> +   unsigned char   count;  /* # task groups 
>> remaining to be serviced */
>> unsigned char   nr; /* # tasks remaining 
>> for cookie */
>> unsigned short  qlen;   /* total # tasks 
>> waiting in queue */
>> struct rpc_timertimer_list;
>> diff --git a/net/sunrpc/sched.c b/net/sunrpc/sched.c
>> index 73ad57a59989..e8fcd4f098bb 100644
>> --- a/net/sunrpc/sched.c
>> +++ b/net/sunrpc/sched.c
>> @@ -117,6 +117,8 @@ static void rpc_set_waitqueue_priority(struct 
>> rpc_wait_queue *queue, int priorit
>> rpc_rotate_queue_owner(queue);
>> queue->priority = priority;
>> }
>> +   if (queue->count != 255)
>> +   queue->count = 1 << (priority * 2);
>>  }
>>
>>  static void rpc_set_waitqueue_owner(struct rpc_wait_queue *queue, pid_t pid)
>> @@ -144,8 +146,10 @@ static void __rpc_add_wait_queue_priority(struct 
>> rpc_wait_queue *queue,
>> INIT_LIST_HEAD(>u.tk_wait.links);
>> if (unlikely(queue_priority > queue->maxpriority))
>> queue_priority = queue->maxpriority;
>> -   if (queue_priority > queue->priority)
>> -   rpc_set_waitqueue_priority(queue, queue_priority);
>> +   if (queue->count == 255) {
>> +   if (queue_priority > queue->priority)
>> +   rpc_set_waitqueue_priority(queue, queue_priority);
>> +   }
>> q = >tasks[queue_priority];
>> list_for_each_entry(t, q, u.tk_wait.list) {
>> if (t->tk_owner == task->tk_owner) {
>> @@ -401,6 +405,7 @@ void rpc_sleep_on_priority(struct rpc_wait_queue *q, 
>> struct rpc_task *task,
>>  * Protect the queue operations.
>>  */
>> spin_lock_bh(>lock);
>> +   q->count = 255;
>> __rpc_sleep_on_priority(q, task, action, priority - 
>> RPC_PRIORITY_LOW);
>> spin_unlock_bh(>lock);
>>  }
>> @@ -478,7 +483,8 @@ static struct rpc_task 
>> *__rpc_find_next_queued_priority(struct rpc_wait_queue *q
>> /*
>>  * Check if we need to switch queues.
>>  */
>> -   goto new_owner;
>> +   if (queue->count == 255 || --queue->count)
>> +   goto new_owner;
>> }
>>
>> /*
>>
>
> Are we sure there is value in keeping FLUSH_LOWPRI for background writes?

There is currently also FLUSH_HIGHPRI for "for_reclaim" writes.
Should they be allowed to starve reads?

Re: [PATCH 0/15] copy offload patches

[Martin K. Petersen]

> "Mikulas" == Mikulas Patocka  writes:

Mikulas> Is there some software iSCSI implementation that supports
Mikulas> token-based copy? So that I could try to make support for it.

I did write support for token-based copy but it's in a different branch
from the xcopy stuff. I will have to reconcile those two branches and
then layer your stuff on top.

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

Re: [PATCH 1/2] arm64: Improve error reporting on set_pte_at() checks

[Andrew Pinski]

On Tue, Dec 9, 2015 at 17:26:56, Catalin Marinas
 wrote:
>
> Currently the BUG_ON() checks do not give enough information about the PTEs 
> being set. This patch changes BUG_ON to WARN_ONCE and dumps the values of the 
> old and new PTEs.


This change broke building the mantis driver:

In file included from ./arch/arm64/include/asm/io.h:30:0,
 from drivers/media/pci/mantis/mantis_i2c.c:21:
./arch/arm64/include/asm/pgtable.h: In function ‘set_pte_at’:
./arch/arm64/include/asm/pgtable.h:281:3: error: implicit declaration
of function ‘BUILD_BUG_ON_INVALID’
[-Werror=implicit-function-declaration]
   VM_WARN_ONCE(!pte_young(pte),
   ^

Thanks,
Andrew Pinski

>
> Signed-off-by: Catalin Marinas 
> Cc: Will Deacon 
> ---
>   arch/arm64/include/asm/pgtable.h | 11 +++
>   1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/include/asm/pgtable.h
> b/arch/arm64/include/asm/pgtable.h
> index 7e074f93f383..002dc61a4dff 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -276,10 +276,13 @@ static inline void set_pte_at(struct mm_struct *mm, 
> unsigned long addr,
>  * hardware updates of the pte (ptep_set_access_flags safely changes
>  * valid ptes without going through an invalid entry).
>  */
> -   if (IS_ENABLED(CONFIG_DEBUG_VM) && IS_ENABLED(CONFIG_ARM64_HW_AFDBM) 
> &&
> -   pte_valid(*ptep)) {
> -   BUG_ON(!pte_young(pte));
> -   BUG_ON(pte_write(*ptep) && !pte_dirty(pte));
> +   if (IS_ENABLED(CONFIG_ARM64_HW_AFDBM) && pte_valid(*ptep)) {
> +   VM_WARN_ONCE(!pte_young(pte),
> +"%s: racy access flag clearing: %016llx -> 
> %016llx",
> +__func__, pte_val(*ptep), pte_val(pte));
> +   VM_WARN_ONCE(pte_write(*ptep) && !pte_dirty(pte),
> +"%s: racy dirty state clearing: %016llx -> 
> %016llx",
> +__func__, pte_val(*ptep), pte_val(pte));
> }
>
> set_pte(ptep, pte);
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
>
--
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/