Re: [PATCH v7 0/8] Add PWM and IIO timer drivers for STM32

[Benjamin Gaignard]

2017-01-05 15:49 GMT+01:00 Lee Jones :
> On Thu, 05 Jan 2017, Benjamin Gaignard wrote:
>
>> version 7:
>> - rebase on v4.10-rc2
>> - remove iio_device code from driver and keep only the trigger part
>>
>> version 6:
>> - rename stm32-gptimer in stm32-timers.
>> - change "st,stm32-gptimer" compatible to "st,stm32-timers".
>> - modify "st,breakinput" parameter in pwm part.
>> - split DT patch in 2
>>
>> version 5:
>> - fix comments done on version 4
>> - rebased on kernel 4.9-rc8
>> - change nodes names and re-order then by addresses
>>
>> version 4:
>> - fix comments done on version 3
>> - don't use interrupts anymore in IIO timer
>> - detect hardware capabilities at probe time to simplify binding
>>
>> version 3:
>> - no change on mfd and pwm divers patches
>> - add cross reference between bindings
>> - change compatible to "st,stm32-timer-trigger"
>> - fix attributes access rights
>> - use string instead of int for master_mode and slave_mode
>> - document device attributes in sysfs-bus-iio-timer-stm32
>> - update DT with the new compatible
>>
>> version 2:
>> - keep only one compatible per driver
>> - use DT parameters to describe hardware block configuration:
>>   - pwm channels, complementary output, counter size, break input
>>   - triggers accepted and create by IIO timers
>> - change DT to limite use of reference to the node
>> - interrupt is now in IIO timer driver
>> - rename stm32-mfd-timer to stm32-timers (for general purpose timer)
>>
>> The following patches enable PWM and IIO Timer features for STM32 platforms.
>>
>> Those two features are mixed into the registers of the same hardware block
>> (named general purpose timer) which lead to introduce a multifunctions driver
>> on the top of them to be able to share the registers.
>>
>> In STM32f4 14 instances of timer hardware block exist, even if they all have
>> the same register mapping they could have a different number of pwm channels
>> and/or different triggers capabilities. We use various parameters in DT to
>> describe the differences between hardware blocks
>>
>> The MFD (stm32-timers.c) takes care of clock and register mapping
>> by using regmap. stm32_timers structure is provided to its sub-node to
>> share those information.
>>
>> PWM driver is implemented into pwm-stm32.c. Depending of the instance we may
>> have up to 4 channels, sometime with complementary outputs or 32 bits counter
>> instead of 16 bits. Some hardware blocks may also have a break input function
>> which allows to stop pwm depending of a level, defined in devicetree, on an
>> external pin.
>>
>> IIO timer driver (stm32-timer-trigger.c and stm32-timer-trigger.h) define a 
>> list
>> of hardware triggers usable by hardware blocks like ADC, DAC or other timers.
>>
>> The matrix of possible connections between blocks is quite complex so we use
>> trigger names and is_stm32_iio_timer_trigger() function to be sure that
>> triggers are valid and configure the IPs.
>>
>> At run time IIO timer hardware blocks can configure (through "master_mode"
>> IIO device attribute) which internal signal (counter enable, reset,
>> comparison block, etc...) is used to generate the trigger.
>>
>> Benjamin Gaignard (8):
>>   MFD: add bindings for STM32 Timers driver
>>   MFD: add STM32 Timers driver
>>   PWM: add pwm-stm32 DT bindings
>>   PWM: add PWM driver for STM32 plaftorm
>>   IIO: add bindings for STM32 timer trigger driver
>>   IIO: add STM32 timer trigger driver
>>   ARM: dts: stm32: add Timers driver for stm32f429 MCU
>>   ARM: dts: stm32: Enable pwm1 and pwm3 for stm32f469-disco
>
> Any reason why you've dropped all your Acks?
>
> I don't really want to review it again if little is different.
>
> How much MFD related code has changed since the last review?

All my apologies I forgot to add your Acks for MFD parts.

Sorry for that

>
>>  .../ABI/testing/sysfs-bus-iio-timer-stm32  |  29 ++
>>  .../bindings/iio/timer/stm32-timer-trigger.txt |  23 ++
>>  .../devicetree/bindings/mfd/stm32-timers.txt   |  46 +++
>>  .../devicetree/bindings/pwm/pwm-stm32.txt  |  33 ++
>>  arch/arm/boot/dts/stm32f429.dtsi   | 275 +
>>  arch/arm/boot/dts/stm32f469-disco.dts  |  28 ++
>>  drivers/iio/Kconfig|   1 -
>>  drivers/iio/trigger/Kconfig|  10 +
>>  drivers/iio/trigger/Makefile   |   1 +
>>  drivers/iio/trigger/stm32-timer-trigger.c  | 340 
>>  drivers/mfd/Kconfig|  11 +
>>  drivers/mfd/Makefile   |   2 +
>>  drivers/mfd/stm32-timers.c |  80 
>>  drivers/pwm/Kconfig|   9 +
>>  drivers/pwm/Makefile   |   1 +
>>  drivers/pwm/pwm-stm32.c| 434 
>> +
>>  include/linux/iio/timer/stm32-timer-trigger.h  |  62 +++
>>  

Re: [PATCH v7 0/8] Add PWM and IIO timer drivers for STM32

[Benjamin Gaignard]

2017-01-05 15:49 GMT+01:00 Lee Jones :
> On Thu, 05 Jan 2017, Benjamin Gaignard wrote:
>
>> version 7:
>> - rebase on v4.10-rc2
>> - remove iio_device code from driver and keep only the trigger part
>>
>> version 6:
>> - rename stm32-gptimer in stm32-timers.
>> - change "st,stm32-gptimer" compatible to "st,stm32-timers".
>> - modify "st,breakinput" parameter in pwm part.
>> - split DT patch in 2
>>
>> version 5:
>> - fix comments done on version 4
>> - rebased on kernel 4.9-rc8
>> - change nodes names and re-order then by addresses
>>
>> version 4:
>> - fix comments done on version 3
>> - don't use interrupts anymore in IIO timer
>> - detect hardware capabilities at probe time to simplify binding
>>
>> version 3:
>> - no change on mfd and pwm divers patches
>> - add cross reference between bindings
>> - change compatible to "st,stm32-timer-trigger"
>> - fix attributes access rights
>> - use string instead of int for master_mode and slave_mode
>> - document device attributes in sysfs-bus-iio-timer-stm32
>> - update DT with the new compatible
>>
>> version 2:
>> - keep only one compatible per driver
>> - use DT parameters to describe hardware block configuration:
>>   - pwm channels, complementary output, counter size, break input
>>   - triggers accepted and create by IIO timers
>> - change DT to limite use of reference to the node
>> - interrupt is now in IIO timer driver
>> - rename stm32-mfd-timer to stm32-timers (for general purpose timer)
>>
>> The following patches enable PWM and IIO Timer features for STM32 platforms.
>>
>> Those two features are mixed into the registers of the same hardware block
>> (named general purpose timer) which lead to introduce a multifunctions driver
>> on the top of them to be able to share the registers.
>>
>> In STM32f4 14 instances of timer hardware block exist, even if they all have
>> the same register mapping they could have a different number of pwm channels
>> and/or different triggers capabilities. We use various parameters in DT to
>> describe the differences between hardware blocks
>>
>> The MFD (stm32-timers.c) takes care of clock and register mapping
>> by using regmap. stm32_timers structure is provided to its sub-node to
>> share those information.
>>
>> PWM driver is implemented into pwm-stm32.c. Depending of the instance we may
>> have up to 4 channels, sometime with complementary outputs or 32 bits counter
>> instead of 16 bits. Some hardware blocks may also have a break input function
>> which allows to stop pwm depending of a level, defined in devicetree, on an
>> external pin.
>>
>> IIO timer driver (stm32-timer-trigger.c and stm32-timer-trigger.h) define a 
>> list
>> of hardware triggers usable by hardware blocks like ADC, DAC or other timers.
>>
>> The matrix of possible connections between blocks is quite complex so we use
>> trigger names and is_stm32_iio_timer_trigger() function to be sure that
>> triggers are valid and configure the IPs.
>>
>> At run time IIO timer hardware blocks can configure (through "master_mode"
>> IIO device attribute) which internal signal (counter enable, reset,
>> comparison block, etc...) is used to generate the trigger.
>>
>> Benjamin Gaignard (8):
>>   MFD: add bindings for STM32 Timers driver
>>   MFD: add STM32 Timers driver
>>   PWM: add pwm-stm32 DT bindings
>>   PWM: add PWM driver for STM32 plaftorm
>>   IIO: add bindings for STM32 timer trigger driver
>>   IIO: add STM32 timer trigger driver
>>   ARM: dts: stm32: add Timers driver for stm32f429 MCU
>>   ARM: dts: stm32: Enable pwm1 and pwm3 for stm32f469-disco
>
> Any reason why you've dropped all your Acks?
>
> I don't really want to review it again if little is different.
>
> How much MFD related code has changed since the last review?

All my apologies I forgot to add your Acks for MFD parts.

Sorry for that

>
>>  .../ABI/testing/sysfs-bus-iio-timer-stm32  |  29 ++
>>  .../bindings/iio/timer/stm32-timer-trigger.txt |  23 ++
>>  .../devicetree/bindings/mfd/stm32-timers.txt   |  46 +++
>>  .../devicetree/bindings/pwm/pwm-stm32.txt  |  33 ++
>>  arch/arm/boot/dts/stm32f429.dtsi   | 275 +
>>  arch/arm/boot/dts/stm32f469-disco.dts  |  28 ++
>>  drivers/iio/Kconfig|   1 -
>>  drivers/iio/trigger/Kconfig|  10 +
>>  drivers/iio/trigger/Makefile   |   1 +
>>  drivers/iio/trigger/stm32-timer-trigger.c  | 340 
>>  drivers/mfd/Kconfig|  11 +
>>  drivers/mfd/Makefile   |   2 +
>>  drivers/mfd/stm32-timers.c |  80 
>>  drivers/pwm/Kconfig|   9 +
>>  drivers/pwm/Makefile   |   1 +
>>  drivers/pwm/pwm-stm32.c| 434 
>> +
>>  include/linux/iio/timer/stm32-timer-trigger.h  |  62 +++
>>  

Re: INFO: rcu_sched self-detected stall on CPU

[Paul E. McKenney]

On Thu, Jan 05, 2017 at 07:32:45PM +0100, Enrico Mioso wrote:
> Here is a new trace in the meanwhile: reporting it in case it proves useful.
> Thank you very much for your help and patience.

This looks quite similar to the last one.  So there appears to be some
consistency, which is reassuring.  Maybe fewer rather than more bugs in
play here.

Thanx, Paul

> Enrico
> [34839.019680] INFO: rcu_sched self-detected stall on CPU
> [34839.019694] INFO: rcu_sched detected stalls on CPUs/tasks:
> [34839.019711]0-...: (1 GPs behind) idle=3d7/1/0
> softirq=5887188/5887188 fqs=0 [34839.019713] [34839.019725]   0-...:
> (1 GPs behind) idle=3d7/1/0 softirq=5887188/5887188 fqs=0
> [34839.019727] [34839.019733]  (t=39875 jiffies g=3086597 c=3086596
> q=1)
> [34839.019744] rcu_sched kthread starved for 39875 jiffies! g3086597 c3086596 
> f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1
> [34839.019751] (detected by 1, t=39875 jiffies, g=3086597, c=3086596, q=1)
> [34839.019755] Task dump for CPU 0:
> [34839.019758] rcu_sched   S0 7  2 0x
> [34839.019768] swapper/0   R  running task [34839.019774] Call
> Trace:
> [34839.019779] 0 0  0 0x0008
> [34839.019783] Call Trace:
> [34839.019808]  ? cpuidle_enter_state+0x16c/0x350
> [34839.019818]  ? __schedule+0x155/0x650
> [34839.019831]  ? _raw_spin_lock_irqsave+0x14/0x40
> [34839.019839]  ? cpuidle_enter+0x14/0x20
> [34839.019850]  ? call_cpuidle+0x21/0x40
> [34839.019857]  schedule+0x2e/0x70
> [34839.019866]  ? do_idle+0xd3/0x1b0
> [34839.019875]  schedule_timeout+0x18f/0x350
> [34839.019885]  ? cpu_startup_entry+0x65/0x70
> [34839.019894]  ? del_timer_sync+0x60/0x60
> [34839.019904]  ? rest_init+0x62/0x70
> [34839.019914]  rcu_gp_kthread+0x575/0xce0
> [34839.019927]  ? start_kernel+0x32c/0x342
> [34839.019935]  ? force_qs_rnp+0x170/0x170
> [34839.019946]  kthread+0xd6/0x110
> [34839.019954]  ? i386_start_kernel+0x90/0x94
> [34839.019963]  ? startup_32_smp+0x16b/0x16d
> [34839.019971]  ? force_qs_rnp+0x170/0x170
> [34839.019981]  ? kthread_create_on_node+0x30/0x30
> [34839.019991] rcu_sched kthread starved for 39875 jiffies! g3086597 c3086596 
> f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1
> [34839.019995] rcu_sched   S
> [34839.020004]  ret_from_fork+0x19/0x24
> [34839.020011] 0 7  2 0x
> [34839.020015] Call Trace:
> [34839.020029]  ? __schedule+0x155/0x650
> [34839.020032] Task dump for CPU 0:
> [34839.020036] swapper/0   R
> [34839.020046]  ? _raw_spin_lock_irqsave+0x14/0x40
> [34839.020049]   running task [34839.020057]  schedule+0x2e/0x70
> [34839.020063] 0 0  0 0x0008
> [34839.020071]  schedule_timeout+0x18f/0x350
> [34839.020075] Call Trace:
> [34839.020083]  ? del_timer_sync+0x60/0x60
> [34839.020096]  rcu_gp_kthread+0x575/0xce0
> [34839.020098]  
> [34839.020109]  sched_show_task+0xf3/0x160
> [34839.020117]  ? force_qs_rnp+0x170/0x170
> [34839.020126]  kthread+0xd6/0x110
> [34839.020133]  dump_cpu_task+0x37/0x40
> [34839.020143]  ? force_qs_rnp+0x170/0x170
> [34839.020153]  rcu_dump_cpu_stacks+0x79/0x95
> [34839.020164]  ? kthread_create_on_node+0x30/0x30
> [34839.020172]  rcu_check_callbacks+0x621/0x770
> [34839.020184]  ret_from_fork+0x19/0x24
> [34839.020191]  ? ttwu_do_activate+0x5f/0x70
> [34839.020203]  update_process_times+0x28/0x50
> [34839.020215]  tick_sched_handle.isra.11+0x2f/0x40
> [34839.020225]  tick_sched_timer+0x3b/0x80
> [34839.020236]  __hrtimer_run_queues+0xdb/0x2b0
> [34839.020247]  ? tick_sched_do_timer+0x60/0x60
> [34839.020258]  hrtimer_interrupt+0x8b/0x180
> [34839.020269]  ? default_send_IPI_mask_logical+0x5f/0x80
> [34839.020281]  tick_handle_oneshot_broadcast+0x14c/0x190
> [34839.020293]  timer_interrupt+0x12/0x20
> [34839.020304]  __handle_irq_event_percpu+0x78/0x190
> [34839.020316]  ? add_interrupt_randomness+0x144/0x1a0
> [34839.020327]  ? handle_level_irq+0xf0/0xf0
> [34839.020336]  handle_irq_event_percpu+0x2c/0x70
> [34839.020346]  handle_irq_event+0x27/0x40
> [34839.020356]  handle_edge_irq+0x5d/0x120
> [34839.020366]  handle_irq+0x9b/0xc0
> [34839.020370]  
> [34839.020380]  do_IRQ+0x3d/0xc0
> [34839.020393]  common_interrupt+0x3a/0x40
> [34839.020405] EIP: cpuidle_enter_state+0x16c/0x350
> [34839.020411] EFLAGS: 00200246 CPU: 0
> [34839.020418] EAX:  EBX: f9c80a40 ECX: 4ebd61d5 EDX: 
> [34839.020425] ESI: 4ebd61d5 EDI: f9c80a50 EBP: d568df2c ESP: d568defc
> [34839.020433]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> [34839.020449]  cpuidle_enter+0x14/0x20
> [34839.020459]  call_cpuidle+0x21/0x40
> [34839.020468]  do_idle+0xd3/0x1b0
> [34839.020478]  cpu_startup_entry+0x65/0x70
> [34839.020488]  rest_init+0x62/0x70
> [34839.020501]  start_kernel+0x32c/0x342
> [34839.020511]  i386_start_kernel+0x90/0x94
> [34839.020521]  startup_32_smp+0x16b/0x16d
> [37701.023799] INFO: rcu_sched self-detected stall on CPU
> [37701.023830]0-...: (2 GPs behind) idle=e63/1/0
> 

Re: INFO: rcu_sched self-detected stall on CPU

[Paul E. McKenney]

On Wed, Jan 04, 2017 at 09:59:13PM +0100, Enrico Mioso wrote:
> Here is my .config: I send it 'cause I wasn't able to determine if I selected 
> the right options.
> Sorry for this long config: I don't know how to represent those infos more 
> efficiently.

You have RCU tracing configured, which is good.

> I would be very glad if you could send me some hints on how to perform 
> ftracing the right way. From past work, my impression was there are different 
> ways it's better to operate depending on how you'll process thedata and what 
> you're looking for.

I usually turn on the tracers via the kernel command line, and rely on a
few strategically placed ftrace_dump() calls.  But Steve is the expert,
so I will defer to him.

Thanx, Paul

> Sorry for the churn,
> thank you very much.
> 
> Enrico
> 
> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/x86 4.10.0-rc2 Kernel Configuration
> #
> # CONFIG_64BIT is not set
> CONFIG_X86_32=y
> CONFIG_X86=y
> CONFIG_INSTRUCTION_DECODER=y
> CONFIG_OUTPUT_FORMAT="elf32-i386"
> CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_MMU=y
> CONFIG_ARCH_MMAP_RND_BITS_MIN=8
> CONFIG_ARCH_MMAP_RND_BITS_MAX=16
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
> CONFIG_NEED_SG_DMA_LENGTH=y
> CONFIG_GENERIC_ISA_DMA=y
> CONFIG_GENERIC_BUG=y
> CONFIG_GENERIC_HWEIGHT=y
> CONFIG_ARCH_MAY_HAVE_PC_FDC=y
> CONFIG_RWSEM_XCHGADD_ALGORITHM=y
> CONFIG_GENERIC_CALIBRATE_DELAY=y
> CONFIG_ARCH_HAS_CPU_RELAX=y
> CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
> CONFIG_HAVE_SETUP_PER_CPU_AREA=y
> CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
> CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
> CONFIG_ARCH_HIBERNATION_POSSIBLE=y
> CONFIG_ARCH_SUSPEND_POSSIBLE=y
> CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
> CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
> CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
> CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
> CONFIG_X86_32_SMP=y
> CONFIG_ARCH_SUPPORTS_UPROBES=y
> CONFIG_FIX_EARLYCON_MEM=y
> CONFIG_DEBUG_RODATA=y
> CONFIG_PGTABLE_LEVELS=2
> CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
> CONFIG_IRQ_WORK=y
> CONFIG_BUILDTIME_EXTABLE_SORT=y
> CONFIG_THREAD_INFO_IN_TASK=y
> 
> #
> # General setup
> #
> CONFIG_INIT_ENV_ARG_LIMIT=32
> CONFIG_CROSS_COMPILE=""
> # CONFIG_COMPILE_TEST is not set
> CONFIG_LOCALVERSION="ho"
> # CONFIG_LOCALVERSION_AUTO is not set
> CONFIG_HAVE_KERNEL_GZIP=y
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_HAVE_KERNEL_LZMA=y
> CONFIG_HAVE_KERNEL_XZ=y
> CONFIG_HAVE_KERNEL_LZO=y
> CONFIG_HAVE_KERNEL_LZ4=y
> # CONFIG_KERNEL_GZIP is not set
> # CONFIG_KERNEL_BZIP2 is not set
> # CONFIG_KERNEL_LZMA is not set
> CONFIG_KERNEL_XZ=y
> # CONFIG_KERNEL_LZO is not set
> # CONFIG_KERNEL_LZ4 is not set
> CONFIG_DEFAULT_HOSTNAME="(gato-saldo)"
> CONFIG_SWAP=y
> CONFIG_SYSVIPC=y
> CONFIG_SYSVIPC_SYSCTL=y
> # CONFIG_POSIX_MQUEUE is not set
> CONFIG_CROSS_MEMORY_ATTACH=y
> CONFIG_FHANDLE=y
> # CONFIG_USELIB is not set
> # CONFIG_AUDIT is not set
> CONFIG_HAVE_ARCH_AUDITSYSCALL=y
> 
> #
> # IRQ subsystem
> #
> CONFIG_GENERIC_IRQ_PROBE=y
> CONFIG_GENERIC_IRQ_SHOW=y
> CONFIG_GENERIC_PENDING_IRQ=y
> CONFIG_IRQ_DOMAIN=y
> CONFIG_IRQ_DOMAIN_HIERARCHY=y
> CONFIG_GENERIC_MSI_IRQ=y
> CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
> # CONFIG_IRQ_DOMAIN_DEBUG is not set
> CONFIG_IRQ_FORCED_THREADING=y
> CONFIG_SPARSE_IRQ=y
> CONFIG_CLOCKSOURCE_WATCHDOG=y
> CONFIG_ARCH_CLOCKSOURCE_DATA=y
> CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
> CONFIG_GENERIC_TIME_VSYSCALL=y
> CONFIG_GENERIC_CLOCKEVENTS=y
> CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
> CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
> CONFIG_GENERIC_CMOS_UPDATE=y
> 
> #
> # Timers subsystem
> #
> CONFIG_TICK_ONESHOT=y
> CONFIG_NO_HZ_COMMON=y
> # CONFIG_HZ_PERIODIC is not set
> CONFIG_NO_HZ_IDLE=y
> # CONFIG_NO_HZ is not set
> CONFIG_HIGH_RES_TIMERS=y
> 
> #
> # CPU/Task time and stats accounting
> #
> CONFIG_TICK_CPU_ACCOUNTING=y
> # CONFIG_IRQ_TIME_ACCOUNTING is not set
> CONFIG_BSD_PROCESS_ACCT=y
> CONFIG_BSD_PROCESS_ACCT_V3=y
> CONFIG_TASKSTATS=y
> CONFIG_TASK_DELAY_ACCT=y
> # CONFIG_TASK_XACCT is not set
> 
> #
> # RCU Subsystem
> #
> CONFIG_TREE_RCU=y
> # CONFIG_RCU_EXPERT is not set
> CONFIG_SRCU=y
> # CONFIG_TASKS_RCU is not set
> CONFIG_RCU_STALL_COMMON=y
> CONFIG_TREE_RCU_TRACE=y
> # CONFIG_RCU_EXPEDITE_BOOT is not set
> CONFIG_BUILD_BIN2C=y
> CONFIG_IKCONFIG=m
> CONFIG_IKCONFIG_PROC=y
> CONFIG_LOG_BUF_SHIFT=18
> CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
> CONFIG_NMI_LOG_BUF_SHIFT=13
> CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
> CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
> CONFIG_CGROUPS=y
> CONFIG_PAGE_COUNTER=y
> CONFIG_MEMCG=y
> CONFIG_MEMCG_SWAP=y
> # CONFIG_MEMCG_SWAP_ENABLED is not set
> # CONFIG_BLK_CGROUP is not set
> # CONFIG_CGROUP_SCHED is not set
> CONFIG_CGROUP_PIDS=y
> # CONFIG_CGROUP_FREEZER is not set
> CONFIG_CGROUP_HUGETLB=y
> # CONFIG_CPUSETS is not set
> # CONFIG_CGROUP_DEVICE is not set
> CONFIG_CGROUP_CPUACCT=y
> 

Re: INFO: rcu_sched self-detected stall on CPU

[Paul E. McKenney]

On Thu, Jan 05, 2017 at 07:32:45PM +0100, Enrico Mioso wrote:
> Here is a new trace in the meanwhile: reporting it in case it proves useful.
> Thank you very much for your help and patience.

This looks quite similar to the last one.  So there appears to be some
consistency, which is reassuring.  Maybe fewer rather than more bugs in
play here.

Thanx, Paul

> Enrico
> [34839.019680] INFO: rcu_sched self-detected stall on CPU
> [34839.019694] INFO: rcu_sched detected stalls on CPUs/tasks:
> [34839.019711]0-...: (1 GPs behind) idle=3d7/1/0
> softirq=5887188/5887188 fqs=0 [34839.019713] [34839.019725]   0-...:
> (1 GPs behind) idle=3d7/1/0 softirq=5887188/5887188 fqs=0
> [34839.019727] [34839.019733]  (t=39875 jiffies g=3086597 c=3086596
> q=1)
> [34839.019744] rcu_sched kthread starved for 39875 jiffies! g3086597 c3086596 
> f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1
> [34839.019751] (detected by 1, t=39875 jiffies, g=3086597, c=3086596, q=1)
> [34839.019755] Task dump for CPU 0:
> [34839.019758] rcu_sched   S0 7  2 0x
> [34839.019768] swapper/0   R  running task [34839.019774] Call
> Trace:
> [34839.019779] 0 0  0 0x0008
> [34839.019783] Call Trace:
> [34839.019808]  ? cpuidle_enter_state+0x16c/0x350
> [34839.019818]  ? __schedule+0x155/0x650
> [34839.019831]  ? _raw_spin_lock_irqsave+0x14/0x40
> [34839.019839]  ? cpuidle_enter+0x14/0x20
> [34839.019850]  ? call_cpuidle+0x21/0x40
> [34839.019857]  schedule+0x2e/0x70
> [34839.019866]  ? do_idle+0xd3/0x1b0
> [34839.019875]  schedule_timeout+0x18f/0x350
> [34839.019885]  ? cpu_startup_entry+0x65/0x70
> [34839.019894]  ? del_timer_sync+0x60/0x60
> [34839.019904]  ? rest_init+0x62/0x70
> [34839.019914]  rcu_gp_kthread+0x575/0xce0
> [34839.019927]  ? start_kernel+0x32c/0x342
> [34839.019935]  ? force_qs_rnp+0x170/0x170
> [34839.019946]  kthread+0xd6/0x110
> [34839.019954]  ? i386_start_kernel+0x90/0x94
> [34839.019963]  ? startup_32_smp+0x16b/0x16d
> [34839.019971]  ? force_qs_rnp+0x170/0x170
> [34839.019981]  ? kthread_create_on_node+0x30/0x30
> [34839.019991] rcu_sched kthread starved for 39875 jiffies! g3086597 c3086596 
> f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1
> [34839.019995] rcu_sched   S
> [34839.020004]  ret_from_fork+0x19/0x24
> [34839.020011] 0 7  2 0x
> [34839.020015] Call Trace:
> [34839.020029]  ? __schedule+0x155/0x650
> [34839.020032] Task dump for CPU 0:
> [34839.020036] swapper/0   R
> [34839.020046]  ? _raw_spin_lock_irqsave+0x14/0x40
> [34839.020049]   running task [34839.020057]  schedule+0x2e/0x70
> [34839.020063] 0 0  0 0x0008
> [34839.020071]  schedule_timeout+0x18f/0x350
> [34839.020075] Call Trace:
> [34839.020083]  ? del_timer_sync+0x60/0x60
> [34839.020096]  rcu_gp_kthread+0x575/0xce0
> [34839.020098]  
> [34839.020109]  sched_show_task+0xf3/0x160
> [34839.020117]  ? force_qs_rnp+0x170/0x170
> [34839.020126]  kthread+0xd6/0x110
> [34839.020133]  dump_cpu_task+0x37/0x40
> [34839.020143]  ? force_qs_rnp+0x170/0x170
> [34839.020153]  rcu_dump_cpu_stacks+0x79/0x95
> [34839.020164]  ? kthread_create_on_node+0x30/0x30
> [34839.020172]  rcu_check_callbacks+0x621/0x770
> [34839.020184]  ret_from_fork+0x19/0x24
> [34839.020191]  ? ttwu_do_activate+0x5f/0x70
> [34839.020203]  update_process_times+0x28/0x50
> [34839.020215]  tick_sched_handle.isra.11+0x2f/0x40
> [34839.020225]  tick_sched_timer+0x3b/0x80
> [34839.020236]  __hrtimer_run_queues+0xdb/0x2b0
> [34839.020247]  ? tick_sched_do_timer+0x60/0x60
> [34839.020258]  hrtimer_interrupt+0x8b/0x180
> [34839.020269]  ? default_send_IPI_mask_logical+0x5f/0x80
> [34839.020281]  tick_handle_oneshot_broadcast+0x14c/0x190
> [34839.020293]  timer_interrupt+0x12/0x20
> [34839.020304]  __handle_irq_event_percpu+0x78/0x190
> [34839.020316]  ? add_interrupt_randomness+0x144/0x1a0
> [34839.020327]  ? handle_level_irq+0xf0/0xf0
> [34839.020336]  handle_irq_event_percpu+0x2c/0x70
> [34839.020346]  handle_irq_event+0x27/0x40
> [34839.020356]  handle_edge_irq+0x5d/0x120
> [34839.020366]  handle_irq+0x9b/0xc0
> [34839.020370]  
> [34839.020380]  do_IRQ+0x3d/0xc0
> [34839.020393]  common_interrupt+0x3a/0x40
> [34839.020405] EIP: cpuidle_enter_state+0x16c/0x350
> [34839.020411] EFLAGS: 00200246 CPU: 0
> [34839.020418] EAX:  EBX: f9c80a40 ECX: 4ebd61d5 EDX: 
> [34839.020425] ESI: 4ebd61d5 EDI: f9c80a50 EBP: d568df2c ESP: d568defc
> [34839.020433]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> [34839.020449]  cpuidle_enter+0x14/0x20
> [34839.020459]  call_cpuidle+0x21/0x40
> [34839.020468]  do_idle+0xd3/0x1b0
> [34839.020478]  cpu_startup_entry+0x65/0x70
> [34839.020488]  rest_init+0x62/0x70
> [34839.020501]  start_kernel+0x32c/0x342
> [34839.020511]  i386_start_kernel+0x90/0x94
> [34839.020521]  startup_32_smp+0x16b/0x16d
> [37701.023799] INFO: rcu_sched self-detected stall on CPU
> [37701.023830]0-...: (2 GPs behind) idle=e63/1/0
> 

Re: INFO: rcu_sched self-detected stall on CPU

[Paul E. McKenney]

On Wed, Jan 04, 2017 at 09:59:13PM +0100, Enrico Mioso wrote:
> Here is my .config: I send it 'cause I wasn't able to determine if I selected 
> the right options.
> Sorry for this long config: I don't know how to represent those infos more 
> efficiently.

You have RCU tracing configured, which is good.

> I would be very glad if you could send me some hints on how to perform 
> ftracing the right way. From past work, my impression was there are different 
> ways it's better to operate depending on how you'll process thedata and what 
> you're looking for.

I usually turn on the tracers via the kernel command line, and rely on a
few strategically placed ftrace_dump() calls.  But Steve is the expert,
so I will defer to him.

Thanx, Paul

> Sorry for the churn,
> thank you very much.
> 
> Enrico
> 
> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/x86 4.10.0-rc2 Kernel Configuration
> #
> # CONFIG_64BIT is not set
> CONFIG_X86_32=y
> CONFIG_X86=y
> CONFIG_INSTRUCTION_DECODER=y
> CONFIG_OUTPUT_FORMAT="elf32-i386"
> CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_MMU=y
> CONFIG_ARCH_MMAP_RND_BITS_MIN=8
> CONFIG_ARCH_MMAP_RND_BITS_MAX=16
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
> CONFIG_NEED_SG_DMA_LENGTH=y
> CONFIG_GENERIC_ISA_DMA=y
> CONFIG_GENERIC_BUG=y
> CONFIG_GENERIC_HWEIGHT=y
> CONFIG_ARCH_MAY_HAVE_PC_FDC=y
> CONFIG_RWSEM_XCHGADD_ALGORITHM=y
> CONFIG_GENERIC_CALIBRATE_DELAY=y
> CONFIG_ARCH_HAS_CPU_RELAX=y
> CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
> CONFIG_HAVE_SETUP_PER_CPU_AREA=y
> CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
> CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
> CONFIG_ARCH_HIBERNATION_POSSIBLE=y
> CONFIG_ARCH_SUSPEND_POSSIBLE=y
> CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
> CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
> CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
> CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
> CONFIG_X86_32_SMP=y
> CONFIG_ARCH_SUPPORTS_UPROBES=y
> CONFIG_FIX_EARLYCON_MEM=y
> CONFIG_DEBUG_RODATA=y
> CONFIG_PGTABLE_LEVELS=2
> CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
> CONFIG_IRQ_WORK=y
> CONFIG_BUILDTIME_EXTABLE_SORT=y
> CONFIG_THREAD_INFO_IN_TASK=y
> 
> #
> # General setup
> #
> CONFIG_INIT_ENV_ARG_LIMIT=32
> CONFIG_CROSS_COMPILE=""
> # CONFIG_COMPILE_TEST is not set
> CONFIG_LOCALVERSION="ho"
> # CONFIG_LOCALVERSION_AUTO is not set
> CONFIG_HAVE_KERNEL_GZIP=y
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_HAVE_KERNEL_LZMA=y
> CONFIG_HAVE_KERNEL_XZ=y
> CONFIG_HAVE_KERNEL_LZO=y
> CONFIG_HAVE_KERNEL_LZ4=y
> # CONFIG_KERNEL_GZIP is not set
> # CONFIG_KERNEL_BZIP2 is not set
> # CONFIG_KERNEL_LZMA is not set
> CONFIG_KERNEL_XZ=y
> # CONFIG_KERNEL_LZO is not set
> # CONFIG_KERNEL_LZ4 is not set
> CONFIG_DEFAULT_HOSTNAME="(gato-saldo)"
> CONFIG_SWAP=y
> CONFIG_SYSVIPC=y
> CONFIG_SYSVIPC_SYSCTL=y
> # CONFIG_POSIX_MQUEUE is not set
> CONFIG_CROSS_MEMORY_ATTACH=y
> CONFIG_FHANDLE=y
> # CONFIG_USELIB is not set
> # CONFIG_AUDIT is not set
> CONFIG_HAVE_ARCH_AUDITSYSCALL=y
> 
> #
> # IRQ subsystem
> #
> CONFIG_GENERIC_IRQ_PROBE=y
> CONFIG_GENERIC_IRQ_SHOW=y
> CONFIG_GENERIC_PENDING_IRQ=y
> CONFIG_IRQ_DOMAIN=y
> CONFIG_IRQ_DOMAIN_HIERARCHY=y
> CONFIG_GENERIC_MSI_IRQ=y
> CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
> # CONFIG_IRQ_DOMAIN_DEBUG is not set
> CONFIG_IRQ_FORCED_THREADING=y
> CONFIG_SPARSE_IRQ=y
> CONFIG_CLOCKSOURCE_WATCHDOG=y
> CONFIG_ARCH_CLOCKSOURCE_DATA=y
> CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
> CONFIG_GENERIC_TIME_VSYSCALL=y
> CONFIG_GENERIC_CLOCKEVENTS=y
> CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
> CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
> CONFIG_GENERIC_CMOS_UPDATE=y
> 
> #
> # Timers subsystem
> #
> CONFIG_TICK_ONESHOT=y
> CONFIG_NO_HZ_COMMON=y
> # CONFIG_HZ_PERIODIC is not set
> CONFIG_NO_HZ_IDLE=y
> # CONFIG_NO_HZ is not set
> CONFIG_HIGH_RES_TIMERS=y
> 
> #
> # CPU/Task time and stats accounting
> #
> CONFIG_TICK_CPU_ACCOUNTING=y
> # CONFIG_IRQ_TIME_ACCOUNTING is not set
> CONFIG_BSD_PROCESS_ACCT=y
> CONFIG_BSD_PROCESS_ACCT_V3=y
> CONFIG_TASKSTATS=y
> CONFIG_TASK_DELAY_ACCT=y
> # CONFIG_TASK_XACCT is not set
> 
> #
> # RCU Subsystem
> #
> CONFIG_TREE_RCU=y
> # CONFIG_RCU_EXPERT is not set
> CONFIG_SRCU=y
> # CONFIG_TASKS_RCU is not set
> CONFIG_RCU_STALL_COMMON=y
> CONFIG_TREE_RCU_TRACE=y
> # CONFIG_RCU_EXPEDITE_BOOT is not set
> CONFIG_BUILD_BIN2C=y
> CONFIG_IKCONFIG=m
> CONFIG_IKCONFIG_PROC=y
> CONFIG_LOG_BUF_SHIFT=18
> CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
> CONFIG_NMI_LOG_BUF_SHIFT=13
> CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
> CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
> CONFIG_CGROUPS=y
> CONFIG_PAGE_COUNTER=y
> CONFIG_MEMCG=y
> CONFIG_MEMCG_SWAP=y
> # CONFIG_MEMCG_SWAP_ENABLED is not set
> # CONFIG_BLK_CGROUP is not set
> # CONFIG_CGROUP_SCHED is not set
> CONFIG_CGROUP_PIDS=y
> # CONFIG_CGROUP_FREEZER is not set
> CONFIG_CGROUP_HUGETLB=y
> # CONFIG_CPUSETS is not set
> # CONFIG_CGROUP_DEVICE is not set
> CONFIG_CGROUP_CPUACCT=y
> 

Re: [PATCH 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC

[Sean Wang]

Hi Andi,

Thank for your reminder. I will refine the code based on your work.
to have elegant code and easy error handling.

Sean

On Fri, 2017-01-06 at 12:43 +0900, Andi Shyti wrote:
> Hi Sean,
> 
> > +   ir->rc = rc_allocate_device();
> 
> Yes, you should use devm_rc_allocate_device(...)
> 
> Besides, standing to this patch which is not in yet:
> 
> https://lkml.org/lkml/2016/12/18/39
> 
> rc_allocate_device should provide the driver type during
> allocation, so it should be:
> 
>   ir->rc = rc_allocate_device(RC_DRIVER_IR_RAW);
> 
> and this line can be removed:
> 
> > +   ir->rc->driver_type = RC_DRIVER_IR_RAW;
> 
> I don't know when Mauro will take the patch above.
> 
> Andi

Re: [PATCH 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC

[Sean Wang]

Hi Andi,

Thank for your reminder. I will refine the code based on your work.
to have elegant code and easy error handling.

Sean

On Fri, 2017-01-06 at 12:43 +0900, Andi Shyti wrote:
> Hi Sean,
> 
> > +   ir->rc = rc_allocate_device();
> 
> Yes, you should use devm_rc_allocate_device(...)
> 
> Besides, standing to this patch which is not in yet:
> 
> https://lkml.org/lkml/2016/12/18/39
> 
> rc_allocate_device should provide the driver type during
> allocation, so it should be:
> 
>   ir->rc = rc_allocate_device(RC_DRIVER_IR_RAW);
> 
> and this line can be removed:
> 
> > +   ir->rc->driver_type = RC_DRIVER_IR_RAW;
> 
> I don't know when Mauro will take the patch above.
> 
> Andi

Re: [PATCH v3 1/5] arm64: dts: exynos5433: TM2/E: Fix wrong information of ldo23 and ldo25

[Krzysztof Kozlowski]

On Fri, Jan 06, 2017 at 12:59:05PM +0900, Jaechul Lee wrote:
> From: Chanwoo Choi 
> 
> This patch fixes the wrong information of ldo23 and ldo25 on both TM2 and 
> TM2E.

Please describe what is exactly wrong and how it affects the
system/user. This is going to the fixes so it needs a good explanation.

> 
> Fixes: 01e5d2352152 ("arm64: dts: exynos: Add dts file for Exynos5433-based 
> TM2 board")
> Signed-off-by: Chanwoo Choi 
> Signed-off-by: Andi Shyti 
> Signed-off-by: Jaechul Lee 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  |  7 ---
>  arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 10 --
>  2 files changed, 4 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
> b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index 3b5215c..e8971f4 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -504,9 +504,9 @@
>   };
>  
>   ldo23_reg: LDO23 {
> - regulator-name = "CAM_SEN_CORE_1.2V_AP";
> + regulator-name = "CAM_SEN_CORE_1.05V_AP";
>   regulator-min-microvolt = <105>;
> - regulator-max-microvolt = <120>;
> + regulator-max-microvolt = <105>;
>   };
>  
>   ldo24_reg: LDO24 {
> @@ -516,9 +516,10 @@
>   };
>  
>   ldo25_reg: LDO25 {
> - regulator-name = "CAM_SEN_A2.8V_AP";
> + regulator-name = "UNUSED_LDO25";
>   regulator-min-microvolt = <280>;
>   regulator-max-microvolt = <280>;
> + regulator-always-off;

Don't add it. See my other patch.

Best regards,
Krzysztof

>   };
>  
>   ldo26_reg: LDO26 {
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts 
> b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
> index 1db4e7f..854c583 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
> @@ -18,16 +18,6 @@
>   compatible = "samsung,tm2e", "samsung,exynos5433";
>  };
>  
> -_reg {
> - regulator-name = "CAM_SEN_CORE_1.025V_AP";
> - regulator-max-microvolt = <105>;
> -};
> -
> -_reg {
> - regulator-name = "UNUSED_LDO25";
> - regulator-always-off;
> -};
> -
>  _reg {
>   regulator-name = "TSP_VDD_1.8V_AP";
>   regulator-min-microvolt = <180>;
> -- 
> 2.7.4
> 

Re: [PATCH v3 1/5] arm64: dts: exynos5433: TM2/E: Fix wrong information of ldo23 and ldo25

[Krzysztof Kozlowski]

On Fri, Jan 06, 2017 at 12:59:05PM +0900, Jaechul Lee wrote:
> From: Chanwoo Choi 
> 
> This patch fixes the wrong information of ldo23 and ldo25 on both TM2 and 
> TM2E.

Please describe what is exactly wrong and how it affects the
system/user. This is going to the fixes so it needs a good explanation.

> 
> Fixes: 01e5d2352152 ("arm64: dts: exynos: Add dts file for Exynos5433-based 
> TM2 board")
> Signed-off-by: Chanwoo Choi 
> Signed-off-by: Andi Shyti 
> Signed-off-by: Jaechul Lee 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  |  7 ---
>  arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 10 --
>  2 files changed, 4 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
> b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index 3b5215c..e8971f4 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -504,9 +504,9 @@
>   };
>  
>   ldo23_reg: LDO23 {
> - regulator-name = "CAM_SEN_CORE_1.2V_AP";
> + regulator-name = "CAM_SEN_CORE_1.05V_AP";
>   regulator-min-microvolt = <105>;
> - regulator-max-microvolt = <120>;
> + regulator-max-microvolt = <105>;
>   };
>  
>   ldo24_reg: LDO24 {
> @@ -516,9 +516,10 @@
>   };
>  
>   ldo25_reg: LDO25 {
> - regulator-name = "CAM_SEN_A2.8V_AP";
> + regulator-name = "UNUSED_LDO25";
>   regulator-min-microvolt = <280>;
>   regulator-max-microvolt = <280>;
> + regulator-always-off;

Don't add it. See my other patch.

Best regards,
Krzysztof

>   };
>  
>   ldo26_reg: LDO26 {
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts 
> b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
> index 1db4e7f..854c583 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
> @@ -18,16 +18,6 @@
>   compatible = "samsung,tm2e", "samsung,exynos5433";
>  };
>  
> -_reg {
> - regulator-name = "CAM_SEN_CORE_1.025V_AP";
> - regulator-max-microvolt = <105>;
> -};
> -
> -_reg {
> - regulator-name = "UNUSED_LDO25";
> - regulator-always-off;
> -};
> -
>  _reg {
>   regulator-name = "TSP_VDD_1.8V_AP";
>   regulator-min-microvolt = <180>;
> -- 
> 2.7.4
> 

Re: [PATCH 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC

[Sean Wang]

Hi Sean,

Thanks for your effort for code reviewing. I add comments inline. 

On Thu, 2017-01-05 at 17:12 +, Sean Young wrote:
> Hi Sean,
> 
> Some review comments.
> 
> On Fri, Jan 06, 2017 at 12:06:24AM +0800, sean.w...@mediatek.com wrote:
> > From: Sean Wang 
> > 
> > This patch adds driver for IR controller on
> > Mediatek MT7623 SoC. Currently testing successfully
> > on NEC and SONY remote controller only but it should
> > work on others (lirc, rc-5 and rc-6).
> > 
> > Signed-off-by: Sean Wang 
> > ---
> >  drivers/media/rc/Kconfig   |  10 ++
> >  drivers/media/rc/Makefile  |   1 +
> >  drivers/media/rc/mtk-cir.c | 319 
> > +
> >  3 files changed, 330 insertions(+)
> >  create mode 100644 linux-4.8.rc1_p0/drivers/media/rc/mtk-cir.c
> > 
> > diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> > index 370e16e..626c500 100644
> > --- a/drivers/media/rc/Kconfig
> > +++ b/drivers/media/rc/Kconfig
> > @@ -389,4 +389,14 @@ config IR_SUNXI
> >To compile this driver as a module, choose M here: the module will
> >be called sunxi-ir.
> >  
> > +config IR_MTK
> > +   tristate "Mediatek IR remote control"
> > +   depends on RC_CORE
> > +   depends on ARCH_MEDIATEK || COMPILE_TEST
> > +   ---help---
> > +  Say Y if you want to use Mediatek internal IR Controller
> > +
> > +  To compile this driver as a module, choose M here: the module will
> > +  be called mtk-cir.
> > +
> >  endif #RC_DEVICES
> > diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> > index 379a5c0..505908d 100644
> > --- a/drivers/media/rc/Makefile
> > +++ b/drivers/media/rc/Makefile
> > @@ -37,3 +37,4 @@ obj-$(CONFIG_IR_TTUSBIR) += ttusbir.o
> >  obj-$(CONFIG_RC_ST) += st_rc.o
> >  obj-$(CONFIG_IR_SUNXI) += sunxi-cir.o
> >  obj-$(CONFIG_IR_IMG) += img-ir/
> > +obj-$(CONFIG_IR_MTK) += mtk-cir.o
> > diff --git a/drivers/media/rc/mtk-cir.c b/drivers/media/rc/mtk-cir.c
> > new file mode 100644
> > index 000..4fa4cab
> > --- /dev/null
> > +++ b/drivers/media/rc/mtk-cir.c
> > @@ -0,0 +1,319 @@
> > +/*
> > + * Driver for Mediatek MT7623 IR Receiver Controller
> > + *
> > + * Copyright (C) 2017 Sean Wang 
> > + *
> > + * 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.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define MTK_IR_DEV "mtk-ir"
> 
> KBUILD_MODNAME could be used instead. Currently the module is called
> mtk-cir but the rc device will have driver name mtk-ir.


okay. i will use this instead of this insistent coding.

> > +
> > +/* Register to enable PWM and IR */
> > +#define MTK_CONFIG_HIGH_REG   0x0c
> > +/* Enable IR pulse width detection */
> > +#define MTK_PWM_EN   BIT(13)
> > +/* Enable IR hardware function */
> > +#define MTK_IR_ENBIT(0)
> > +
> > +/* Register to setting sample period */
> > +#define MTK_CONFIG_LOW_REG0x10
> > +/* Field to set sample period */
> > +#define CHK_PERIOD   0xC00
> > +#define MTK_CHK_PERIOD(((CHK_PERIOD) << 8) & (GENMASK(20, 8)))
> > +#define MTK_CHK_PERIOD_MASK  (GENMASK(20, 8))
> > +
> > +/* Register to clear state of state machine */
> > +#define MTK_IRCLR_REG 0x20
> > +/* Bit to restart IR receiving */
> > +#define MTK_IRCLRBIT(0)
> > +
> > +/* Register containing pulse width data */
> > +#define MTK_CHKDATA_REG(i)(0x88 + 4 * i)
> > +
> > +/* Register to enable IR interrupt */
> > +#define MTK_IRINT_EN_REG  0xcc
> > +/* Bit to enable interrupt */
> > +#define MTK_IRINT_EN BIT(0)
> > +
> > +/* Register to ack IR interrupt */
> > +#define MTK_IRINT_CLR_REG 0xd0
> > +/* Bit to clear interrupt status */
> > +#define MTK_IRINT_CLRBIT(0)
> > +
> > +/* Number of registers to record the pulse width */
> > +#define MTK_CHKDATA_SZ   17
> > +/* Required frequency */
> > +#define MTK_IR_BASE_CLK  27300
> > +/* Frequency after IR internal divider */
> > +#define MTK_IR_CLK   (MTK_IR_BASE_CLK / 4)
> > +/* Sample period in ns */
> > +#define MTK_IR_SAMPLE(((10ul / MTK_IR_CLK) * 
> > CHK_PERIOD))
> > +/* Indicate the end of IR data*/
> > +#define MTK_IR_END(v)(v == 0xff)
> > +
> > +/* struct mtk_ir - This is the main datasructure for holding the state
> > + * of 

Re: [PATCH 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC

[Sean Wang]

Hi Sean,

Thanks for your effort for code reviewing. I add comments inline. 

On Thu, 2017-01-05 at 17:12 +, Sean Young wrote:
> Hi Sean,
> 
> Some review comments.
> 
> On Fri, Jan 06, 2017 at 12:06:24AM +0800, sean.w...@mediatek.com wrote:
> > From: Sean Wang 
> > 
> > This patch adds driver for IR controller on
> > Mediatek MT7623 SoC. Currently testing successfully
> > on NEC and SONY remote controller only but it should
> > work on others (lirc, rc-5 and rc-6).
> > 
> > Signed-off-by: Sean Wang 
> > ---
> >  drivers/media/rc/Kconfig   |  10 ++
> >  drivers/media/rc/Makefile  |   1 +
> >  drivers/media/rc/mtk-cir.c | 319 
> > +
> >  3 files changed, 330 insertions(+)
> >  create mode 100644 linux-4.8.rc1_p0/drivers/media/rc/mtk-cir.c
> > 
> > diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> > index 370e16e..626c500 100644
> > --- a/drivers/media/rc/Kconfig
> > +++ b/drivers/media/rc/Kconfig
> > @@ -389,4 +389,14 @@ config IR_SUNXI
> >To compile this driver as a module, choose M here: the module will
> >be called sunxi-ir.
> >  
> > +config IR_MTK
> > +   tristate "Mediatek IR remote control"
> > +   depends on RC_CORE
> > +   depends on ARCH_MEDIATEK || COMPILE_TEST
> > +   ---help---
> > +  Say Y if you want to use Mediatek internal IR Controller
> > +
> > +  To compile this driver as a module, choose M here: the module will
> > +  be called mtk-cir.
> > +
> >  endif #RC_DEVICES
> > diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> > index 379a5c0..505908d 100644
> > --- a/drivers/media/rc/Makefile
> > +++ b/drivers/media/rc/Makefile
> > @@ -37,3 +37,4 @@ obj-$(CONFIG_IR_TTUSBIR) += ttusbir.o
> >  obj-$(CONFIG_RC_ST) += st_rc.o
> >  obj-$(CONFIG_IR_SUNXI) += sunxi-cir.o
> >  obj-$(CONFIG_IR_IMG) += img-ir/
> > +obj-$(CONFIG_IR_MTK) += mtk-cir.o
> > diff --git a/drivers/media/rc/mtk-cir.c b/drivers/media/rc/mtk-cir.c
> > new file mode 100644
> > index 000..4fa4cab
> > --- /dev/null
> > +++ b/drivers/media/rc/mtk-cir.c
> > @@ -0,0 +1,319 @@
> > +/*
> > + * Driver for Mediatek MT7623 IR Receiver Controller
> > + *
> > + * Copyright (C) 2017 Sean Wang 
> > + *
> > + * 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.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define MTK_IR_DEV "mtk-ir"
> 
> KBUILD_MODNAME could be used instead. Currently the module is called
> mtk-cir but the rc device will have driver name mtk-ir.


okay. i will use this instead of this insistent coding.

> > +
> > +/* Register to enable PWM and IR */
> > +#define MTK_CONFIG_HIGH_REG   0x0c
> > +/* Enable IR pulse width detection */
> > +#define MTK_PWM_EN   BIT(13)
> > +/* Enable IR hardware function */
> > +#define MTK_IR_ENBIT(0)
> > +
> > +/* Register to setting sample period */
> > +#define MTK_CONFIG_LOW_REG0x10
> > +/* Field to set sample period */
> > +#define CHK_PERIOD   0xC00
> > +#define MTK_CHK_PERIOD(((CHK_PERIOD) << 8) & (GENMASK(20, 8)))
> > +#define MTK_CHK_PERIOD_MASK  (GENMASK(20, 8))
> > +
> > +/* Register to clear state of state machine */
> > +#define MTK_IRCLR_REG 0x20
> > +/* Bit to restart IR receiving */
> > +#define MTK_IRCLRBIT(0)
> > +
> > +/* Register containing pulse width data */
> > +#define MTK_CHKDATA_REG(i)(0x88 + 4 * i)
> > +
> > +/* Register to enable IR interrupt */
> > +#define MTK_IRINT_EN_REG  0xcc
> > +/* Bit to enable interrupt */
> > +#define MTK_IRINT_EN BIT(0)
> > +
> > +/* Register to ack IR interrupt */
> > +#define MTK_IRINT_CLR_REG 0xd0
> > +/* Bit to clear interrupt status */
> > +#define MTK_IRINT_CLRBIT(0)
> > +
> > +/* Number of registers to record the pulse width */
> > +#define MTK_CHKDATA_SZ   17
> > +/* Required frequency */
> > +#define MTK_IR_BASE_CLK  27300
> > +/* Frequency after IR internal divider */
> > +#define MTK_IR_CLK   (MTK_IR_BASE_CLK / 4)
> > +/* Sample period in ns */
> > +#define MTK_IR_SAMPLE(((10ul / MTK_IR_CLK) * 
> > CHK_PERIOD))
> > +/* Indicate the end of IR data*/
> > +#define MTK_IR_END(v)(v == 0xff)
> > +
> > +/* struct mtk_ir - This is the main datasructure for holding the state
> > + * of the driver
> > + * @dev:   The device pointer
> > + * @ir_lock: 

Re: [PATCH 1/2] ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock

[Joseph Qi]

On 17/1/6 15:03, Eric Ren wrote:

On 01/06/2017 02:07 PM, Joseph Qi wrote:

Hi Eric,


On 17/1/5 23:31, Eric Ren wrote:
We are in the situation that we have to avoid recursive cluster 
locking,

but there is no way to check if a cluster lock has been taken by a
precess already.

Mostly, we can avoid recursive locking by writing code carefully.
However, we found that it's very hard to handle the routines that
are invoked directly by vfs code. For instance:

const struct inode_operations ocfs2_file_iops = {
 .permission = ocfs2_permission,
 .get_acl= ocfs2_iop_get_acl,
 .set_acl= ocfs2_iop_set_acl,
};

Both ocfs2_permission() and ocfs2_iop_get_acl() call 
ocfs2_inode_lock(PR):

do_sys_open
  may_open
   inode_permission
ocfs2_permission
 ocfs2_inode_lock() <=== first time
  generic_permission
   get_acl
ocfs2_iop_get_acl
ocfs2_inode_lock() <=== recursive one

A deadlock will occur if a remote EX request comes in between two
of ocfs2_inode_lock(). Briefly describe how the deadlock is formed:

On one hand, OCFS2_LOCK_BLOCKED flag of this lockres is set in
BAST(ocfs2_generic_handle_bast) when downconvert is started
on behalf of the remote EX lock request. Another hand, the recursive
cluster lock (the second one) will be blocked in in 
__ocfs2_cluster_lock()
because of OCFS2_LOCK_BLOCKED. But, the downconvert never complete, 
why?
because there is no chance for the first cluster lock on this node 
to be

unlocked - we block ourselves in the code path.

The idea to fix this issue is mostly taken from gfs2 code.
1. introduce a new field: struct ocfs2_lock_res.l_holders, to
keep track of the processes' pid  who has taken the cluster lock
of this lock resource;
2. introduce a new flag for ocfs2_inode_lock_full: 
OCFS2_META_LOCK_GETBH;
it means just getting back disk inode bh for us if we've got cluster 
lock.

3. export a helper: ocfs2_is_locked_by_me() is used to check if we
have got the cluster lock in the upper code path.

The tracking logic should be used by some of the ocfs2 vfs's callbacks,
to solve the recursive locking issue cuased by the fact that vfs 
routines

can call into each other.

The performance penalty of processing the holder list should only be 
seen

at a few cases where the tracking logic is used, such as get/set acl.

You may ask what if the first time we got a PR lock, and the second 
time
we want a EX lock? fortunately, this case never happens in the real 
world,
as far as I can see, including permission check, 
(get|set)_(acl|attr), and

the gfs2 code also do so.

Signed-off-by: Eric Ren 
---
  fs/ocfs2/dlmglue.c | 47 
---

  fs/ocfs2/dlmglue.h | 18 ++
  fs/ocfs2/ocfs2.h   |  1 +
  3 files changed, 63 insertions(+), 3 deletions(-)

diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
index 83d576f..500bda4 100644
--- a/fs/ocfs2/dlmglue.c
+++ b/fs/ocfs2/dlmglue.c
@@ -532,6 +532,7 @@ void ocfs2_lock_res_init_once(struct 
ocfs2_lock_res *res)

  init_waitqueue_head(>l_event);
  INIT_LIST_HEAD(>l_blocked_list);
  INIT_LIST_HEAD(>l_mask_waiters);
+INIT_LIST_HEAD(>l_holders);
  }
void ocfs2_inode_lock_res_init(struct ocfs2_lock_res *res,
@@ -749,6 +750,45 @@ void ocfs2_lock_res_free(struct ocfs2_lock_res 
*res)

  res->l_flags = 0UL;
  }
  +inline void ocfs2_add_holder(struct ocfs2_lock_res *lockres,
+   struct ocfs2_holder *oh)
+{
+INIT_LIST_HEAD(>oh_list);
+oh->oh_owner_pid =  get_pid(task_pid(current));
+
+spin_lock(>l_lock);
+list_add_tail(>oh_list, >l_holders);
+spin_unlock(>l_lock);
+}
+
+inline void ocfs2_remove_holder(struct ocfs2_lock_res *lockres,
+   struct ocfs2_holder *oh)
+{
+spin_lock(>l_lock);
+list_del(>oh_list);
+spin_unlock(>l_lock);
+
+put_pid(oh->oh_owner_pid);
+}
+
+inline struct ocfs2_holder *ocfs2_is_locked_by_me(struct 
ocfs2_lock_res *lockres)

+{
+struct ocfs2_holder *oh;
+struct pid *pid;
+
+/* look in the list of holders for one with the current task as 
owner */

+spin_lock(>l_lock);
+pid = task_pid(current);
+list_for_each_entry(oh, >l_holders, oh_list) {
+if (oh->oh_owner_pid == pid)
+goto out;
+}
+oh = NULL;
+out:
+spin_unlock(>l_lock);
+return oh;
+}
Since this ocfs2_holder won't be used in the caller, I suggest just 
return a bool value here.

Something like:
spin_lock();
list_for_each_entry() {
if (oh->oh_owner_pid == pid) {
spin_unlock();
return 1;
}
}
spin_unlock();
return 0;


Aha, you have the point. However, it is also reasonable to return the 
lock holder by the way.
When debugging with printk or crash, it's easy to get the pid of the 
holder without any further

analysis. So, I tend to keep it;-)
IC, but we can also get the ocfs2_holder from ocfs2_lock_res in case of 
coredump, right?

I think it is indirectly in your way, and mismatch with 

Re: [PATCH 1/2] ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock

[Joseph Qi]

On 17/1/6 15:03, Eric Ren wrote:

On 01/06/2017 02:07 PM, Joseph Qi wrote:

Hi Eric,


On 17/1/5 23:31, Eric Ren wrote:
We are in the situation that we have to avoid recursive cluster 
locking,

but there is no way to check if a cluster lock has been taken by a
precess already.

Mostly, we can avoid recursive locking by writing code carefully.
However, we found that it's very hard to handle the routines that
are invoked directly by vfs code. For instance:

const struct inode_operations ocfs2_file_iops = {
 .permission = ocfs2_permission,
 .get_acl= ocfs2_iop_get_acl,
 .set_acl= ocfs2_iop_set_acl,
};

Both ocfs2_permission() and ocfs2_iop_get_acl() call 
ocfs2_inode_lock(PR):

do_sys_open
  may_open
   inode_permission
ocfs2_permission
 ocfs2_inode_lock() <=== first time
  generic_permission
   get_acl
ocfs2_iop_get_acl
ocfs2_inode_lock() <=== recursive one

A deadlock will occur if a remote EX request comes in between two
of ocfs2_inode_lock(). Briefly describe how the deadlock is formed:

On one hand, OCFS2_LOCK_BLOCKED flag of this lockres is set in
BAST(ocfs2_generic_handle_bast) when downconvert is started
on behalf of the remote EX lock request. Another hand, the recursive
cluster lock (the second one) will be blocked in in 
__ocfs2_cluster_lock()
because of OCFS2_LOCK_BLOCKED. But, the downconvert never complete, 
why?
because there is no chance for the first cluster lock on this node 
to be

unlocked - we block ourselves in the code path.

The idea to fix this issue is mostly taken from gfs2 code.
1. introduce a new field: struct ocfs2_lock_res.l_holders, to
keep track of the processes' pid  who has taken the cluster lock
of this lock resource;
2. introduce a new flag for ocfs2_inode_lock_full: 
OCFS2_META_LOCK_GETBH;
it means just getting back disk inode bh for us if we've got cluster 
lock.

3. export a helper: ocfs2_is_locked_by_me() is used to check if we
have got the cluster lock in the upper code path.

The tracking logic should be used by some of the ocfs2 vfs's callbacks,
to solve the recursive locking issue cuased by the fact that vfs 
routines

can call into each other.

The performance penalty of processing the holder list should only be 
seen

at a few cases where the tracking logic is used, such as get/set acl.

You may ask what if the first time we got a PR lock, and the second 
time
we want a EX lock? fortunately, this case never happens in the real 
world,
as far as I can see, including permission check, 
(get|set)_(acl|attr), and

the gfs2 code also do so.

Signed-off-by: Eric Ren 
---
  fs/ocfs2/dlmglue.c | 47 
---

  fs/ocfs2/dlmglue.h | 18 ++
  fs/ocfs2/ocfs2.h   |  1 +
  3 files changed, 63 insertions(+), 3 deletions(-)

diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
index 83d576f..500bda4 100644
--- a/fs/ocfs2/dlmglue.c
+++ b/fs/ocfs2/dlmglue.c
@@ -532,6 +532,7 @@ void ocfs2_lock_res_init_once(struct 
ocfs2_lock_res *res)

  init_waitqueue_head(>l_event);
  INIT_LIST_HEAD(>l_blocked_list);
  INIT_LIST_HEAD(>l_mask_waiters);
+INIT_LIST_HEAD(>l_holders);
  }
void ocfs2_inode_lock_res_init(struct ocfs2_lock_res *res,
@@ -749,6 +750,45 @@ void ocfs2_lock_res_free(struct ocfs2_lock_res 
*res)

  res->l_flags = 0UL;
  }
  +inline void ocfs2_add_holder(struct ocfs2_lock_res *lockres,
+   struct ocfs2_holder *oh)
+{
+INIT_LIST_HEAD(>oh_list);
+oh->oh_owner_pid =  get_pid(task_pid(current));
+
+spin_lock(>l_lock);
+list_add_tail(>oh_list, >l_holders);
+spin_unlock(>l_lock);
+}
+
+inline void ocfs2_remove_holder(struct ocfs2_lock_res *lockres,
+   struct ocfs2_holder *oh)
+{
+spin_lock(>l_lock);
+list_del(>oh_list);
+spin_unlock(>l_lock);
+
+put_pid(oh->oh_owner_pid);
+}
+
+inline struct ocfs2_holder *ocfs2_is_locked_by_me(struct 
ocfs2_lock_res *lockres)

+{
+struct ocfs2_holder *oh;
+struct pid *pid;
+
+/* look in the list of holders for one with the current task as 
owner */

+spin_lock(>l_lock);
+pid = task_pid(current);
+list_for_each_entry(oh, >l_holders, oh_list) {
+if (oh->oh_owner_pid == pid)
+goto out;
+}
+oh = NULL;
+out:
+spin_unlock(>l_lock);
+return oh;
+}
Since this ocfs2_holder won't be used in the caller, I suggest just 
return a bool value here.

Something like:
spin_lock();
list_for_each_entry() {
if (oh->oh_owner_pid == pid) {
spin_unlock();
return 1;
}
}
spin_unlock();
return 0;


Aha, you have the point. However, it is also reasonable to return the 
lock holder by the way.
When debugging with printk or crash, it's easy to get the pid of the 
holder without any further

analysis. So, I tend to keep it;-)
IC, but we can also get the ocfs2_holder from ocfs2_lock_res in case of 
coredump, right?

I think it is indirectly in your way, and mismatch with the function 

Re: [PATCH 2/2] ocfs2: fix deadlocks when taking inode lock at vfs entry points

[Joseph Qi]

On 17/1/6 14:56, Eric Ren wrote:

On 01/06/2017 02:09 PM, Joseph Qi wrote:

Hi Eric,


On 17/1/5 23:31, Eric Ren wrote:
Commit 743b5f1434f5 ("ocfs2: take inode lock in 
ocfs2_iop_set/get_acl()")

results in a deadlock, as the author "Tariq Saeed" realized shortly
after the patch was merged. The discussion happened here
(https://oss.oracle.com/pipermail/ocfs2-devel/2015-September/011085.html). 



The reason why taking cluster inode lock at vfs entry points opens up
a self deadlock window, is explained in the previous patch of this
series.

So far, we have seen two different code paths that have this issue.
1. do_sys_open
  may_open
   inode_permission
ocfs2_permission
 ocfs2_inode_lock() <=== take PR
  generic_permission
   get_acl
ocfs2_iop_get_acl
 ocfs2_inode_lock() <=== take PR
2. fchmod|fchmodat
 chmod_common
  notify_change
   ocfs2_setattr <=== take EX
posix_acl_chmod
 get_acl
  ocfs2_iop_get_acl <=== take PR
 ocfs2_iop_set_acl <=== take EX

Fixes them by adding the tracking logic (in the previous patch) for
these funcs above, ocfs2_permission(), ocfs2_iop_[set|get]_acl(),
ocfs2_setattr().
As described cases above, shall we just add the tracking logic only 
for set/get_acl()?


The idea is to detect recursive locking on the running task stack. 
Take case 1) for example if ocfs2_permisssion()

is not changed:

ocfs2_permission() <=== take PR, ocfs2_holder is not added
   ocfs2_iop_get_acl <=== still take PR, because there is no lock 
holder on the tracking list
I mean we have no need to check if locked by me, just do inode lock and 
add holder.

This will make code more clean, IMO.

Thanks,
Joseph


Thanks for your review;-)
Eric



Thanks,
Joseph


Signed-off-by: Eric Ren 
---
  fs/ocfs2/acl.c  | 39 ++-
  fs/ocfs2/file.c | 44 ++--
  2 files changed, 68 insertions(+), 15 deletions(-)

diff --git a/fs/ocfs2/acl.c b/fs/ocfs2/acl.c
index bed1fcb..c539890 100644
--- a/fs/ocfs2/acl.c
+++ b/fs/ocfs2/acl.c
@@ -284,16 +284,31 @@ int ocfs2_iop_set_acl(struct inode *inode, 
struct posix_acl *acl, int type)

  {
  struct buffer_head *bh = NULL;
  int status = 0;
-
-status = ocfs2_inode_lock(inode, , 1);
+int arg_flags = 0, has_locked;
+struct ocfs2_holder oh;
+struct ocfs2_lock_res *lockres;
+
+lockres = _I(inode)->ip_inode_lockres;
+has_locked = (ocfs2_is_locked_by_me(lockres) != NULL);
+if (has_locked)
+arg_flags = OCFS2_META_LOCK_GETBH;
+status = ocfs2_inode_lock_full(inode, , 1, arg_flags);
  if (status < 0) {
  if (status != -ENOENT)
  mlog_errno(status);
  return status;
  }
+if (!has_locked)
+ocfs2_add_holder(lockres, );
+
  status = ocfs2_set_acl(NULL, inode, bh, type, acl, NULL, NULL);
-ocfs2_inode_unlock(inode, 1);
+
+if (!has_locked) {
+ocfs2_remove_holder(lockres, );
+ocfs2_inode_unlock(inode, 1);
+}
  brelse(bh);
+
  return status;
  }
  @@ -303,21 +318,35 @@ struct posix_acl *ocfs2_iop_get_acl(struct 
inode *inode, int type)

  struct buffer_head *di_bh = NULL;
  struct posix_acl *acl;
  int ret;
+int arg_flags = 0, has_locked;
+struct ocfs2_holder oh;
+struct ocfs2_lock_res *lockres;
osb = OCFS2_SB(inode->i_sb);
  if (!(osb->s_mount_opt & OCFS2_MOUNT_POSIX_ACL))
  return NULL;
-ret = ocfs2_inode_lock(inode, _bh, 0);
+
+lockres = _I(inode)->ip_inode_lockres;
+has_locked = (ocfs2_is_locked_by_me(lockres) != NULL);
+if (has_locked)
+arg_flags = OCFS2_META_LOCK_GETBH;
+ret = ocfs2_inode_lock_full(inode, _bh, 0, arg_flags);
  if (ret < 0) {
  if (ret != -ENOENT)
  mlog_errno(ret);
  return ERR_PTR(ret);
  }
+if (!has_locked)
+ocfs2_add_holder(lockres, );
acl = ocfs2_get_acl_nolock(inode, type, di_bh);
  -ocfs2_inode_unlock(inode, 0);
+if (!has_locked) {
+ocfs2_remove_holder(lockres, );
+ocfs2_inode_unlock(inode, 0);
+}
  brelse(di_bh);
+
  return acl;
  }
  diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c
index c488965..62be75d 100644
--- a/fs/ocfs2/file.c
+++ b/fs/ocfs2/file.c
@@ -1138,6 +1138,9 @@ int ocfs2_setattr(struct dentry *dentry, 
struct iattr *attr)

  handle_t *handle = NULL;
  struct dquot *transfer_to[MAXQUOTAS] = { };
  int qtype;
+int arg_flags = 0, had_lock;
+struct ocfs2_holder oh;
+struct ocfs2_lock_res *lockres;
trace_ocfs2_setattr(inode, dentry,
  (unsigned long long)OCFS2_I(inode)->ip_blkno,
@@ -1173,13 +1176,20 @@ int ocfs2_setattr(struct dentry *dentry, 
struct iattr *attr)

  }
  }
  -status = ocfs2_inode_lock(inode, , 1);
+lockres = _I(inode)->ip_inode_lockres;
+had_lock = (ocfs2_is_locked_by_me(lockres) != NULL);

Re: [PATCH 2/2] ocfs2: fix deadlocks when taking inode lock at vfs entry points

[Joseph Qi]

On 17/1/6 14:56, Eric Ren wrote:

On 01/06/2017 02:09 PM, Joseph Qi wrote:

Hi Eric,


On 17/1/5 23:31, Eric Ren wrote:
Commit 743b5f1434f5 ("ocfs2: take inode lock in 
ocfs2_iop_set/get_acl()")

results in a deadlock, as the author "Tariq Saeed" realized shortly
after the patch was merged. The discussion happened here
(https://oss.oracle.com/pipermail/ocfs2-devel/2015-September/011085.html). 



The reason why taking cluster inode lock at vfs entry points opens up
a self deadlock window, is explained in the previous patch of this
series.

So far, we have seen two different code paths that have this issue.
1. do_sys_open
  may_open
   inode_permission
ocfs2_permission
 ocfs2_inode_lock() <=== take PR
  generic_permission
   get_acl
ocfs2_iop_get_acl
 ocfs2_inode_lock() <=== take PR
2. fchmod|fchmodat
 chmod_common
  notify_change
   ocfs2_setattr <=== take EX
posix_acl_chmod
 get_acl
  ocfs2_iop_get_acl <=== take PR
 ocfs2_iop_set_acl <=== take EX

Fixes them by adding the tracking logic (in the previous patch) for
these funcs above, ocfs2_permission(), ocfs2_iop_[set|get]_acl(),
ocfs2_setattr().
As described cases above, shall we just add the tracking logic only 
for set/get_acl()?


The idea is to detect recursive locking on the running task stack. 
Take case 1) for example if ocfs2_permisssion()

is not changed:

ocfs2_permission() <=== take PR, ocfs2_holder is not added
   ocfs2_iop_get_acl <=== still take PR, because there is no lock 
holder on the tracking list
I mean we have no need to check if locked by me, just do inode lock and 
add holder.

This will make code more clean, IMO.

Thanks,
Joseph


Thanks for your review;-)
Eric



Thanks,
Joseph


Signed-off-by: Eric Ren 
---
  fs/ocfs2/acl.c  | 39 ++-
  fs/ocfs2/file.c | 44 ++--
  2 files changed, 68 insertions(+), 15 deletions(-)

diff --git a/fs/ocfs2/acl.c b/fs/ocfs2/acl.c
index bed1fcb..c539890 100644
--- a/fs/ocfs2/acl.c
+++ b/fs/ocfs2/acl.c
@@ -284,16 +284,31 @@ int ocfs2_iop_set_acl(struct inode *inode, 
struct posix_acl *acl, int type)

  {
  struct buffer_head *bh = NULL;
  int status = 0;
-
-status = ocfs2_inode_lock(inode, , 1);
+int arg_flags = 0, has_locked;
+struct ocfs2_holder oh;
+struct ocfs2_lock_res *lockres;
+
+lockres = _I(inode)->ip_inode_lockres;
+has_locked = (ocfs2_is_locked_by_me(lockres) != NULL);
+if (has_locked)
+arg_flags = OCFS2_META_LOCK_GETBH;
+status = ocfs2_inode_lock_full(inode, , 1, arg_flags);
  if (status < 0) {
  if (status != -ENOENT)
  mlog_errno(status);
  return status;
  }
+if (!has_locked)
+ocfs2_add_holder(lockres, );
+
  status = ocfs2_set_acl(NULL, inode, bh, type, acl, NULL, NULL);
-ocfs2_inode_unlock(inode, 1);
+
+if (!has_locked) {
+ocfs2_remove_holder(lockres, );
+ocfs2_inode_unlock(inode, 1);
+}
  brelse(bh);
+
  return status;
  }
  @@ -303,21 +318,35 @@ struct posix_acl *ocfs2_iop_get_acl(struct 
inode *inode, int type)

  struct buffer_head *di_bh = NULL;
  struct posix_acl *acl;
  int ret;
+int arg_flags = 0, has_locked;
+struct ocfs2_holder oh;
+struct ocfs2_lock_res *lockres;
osb = OCFS2_SB(inode->i_sb);
  if (!(osb->s_mount_opt & OCFS2_MOUNT_POSIX_ACL))
  return NULL;
-ret = ocfs2_inode_lock(inode, _bh, 0);
+
+lockres = _I(inode)->ip_inode_lockres;
+has_locked = (ocfs2_is_locked_by_me(lockres) != NULL);
+if (has_locked)
+arg_flags = OCFS2_META_LOCK_GETBH;
+ret = ocfs2_inode_lock_full(inode, _bh, 0, arg_flags);
  if (ret < 0) {
  if (ret != -ENOENT)
  mlog_errno(ret);
  return ERR_PTR(ret);
  }
+if (!has_locked)
+ocfs2_add_holder(lockres, );
acl = ocfs2_get_acl_nolock(inode, type, di_bh);
  -ocfs2_inode_unlock(inode, 0);
+if (!has_locked) {
+ocfs2_remove_holder(lockres, );
+ocfs2_inode_unlock(inode, 0);
+}
  brelse(di_bh);
+
  return acl;
  }
  diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c
index c488965..62be75d 100644
--- a/fs/ocfs2/file.c
+++ b/fs/ocfs2/file.c
@@ -1138,6 +1138,9 @@ int ocfs2_setattr(struct dentry *dentry, 
struct iattr *attr)

  handle_t *handle = NULL;
  struct dquot *transfer_to[MAXQUOTAS] = { };
  int qtype;
+int arg_flags = 0, had_lock;
+struct ocfs2_holder oh;
+struct ocfs2_lock_res *lockres;
trace_ocfs2_setattr(inode, dentry,
  (unsigned long long)OCFS2_I(inode)->ip_blkno,
@@ -1173,13 +1176,20 @@ int ocfs2_setattr(struct dentry *dentry, 
struct iattr *attr)

  }
  }
  -status = ocfs2_inode_lock(inode, , 1);
+lockres = _I(inode)->ip_inode_lockres;
+had_lock = (ocfs2_is_locked_by_me(lockres) != NULL);
+if 

Re: [PATCH v3 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

[Bjorn Andersson]

On Tue 20 Dec 09:03 PST 2016, Vivek Gautam wrote:

> diff --git a/drivers/phy/phy-qcom-qmp.c b/drivers/phy/phy-qcom-qmp.c
[..]
> +static int qcom_qmp_phy_poweron(struct phy *phy)
[..]
> +
> +err3:

Rather than naming your labels errX, it's idiomatic to give them
descriptive names, e.g. "disable_ref_clk" here.

> + clk_disable_unprepare(qphy->ref_clk);
> +err2:
> + regulator_disable(qphy->vddp_ref_clk);
> +err1:
> + regulator_disable(qphy->vdda_pll);
> +err:
> + regulator_disable(qphy->vdda_phy);
> + return ret;
> +}
[..]
> +static int qcom_qmp_phy_com_init(struct qcom_qmp_phy *qphy)
> +{
> + const struct qmp_phy_cfg *cfg = qphy->cfg;
> + void __iomem *serdes = qphy->serdes;
> + int ret;
> +
> + mutex_lock(>phy_mutex);
> + if (qphy->init_count++) {
> + mutex_unlock(>phy_mutex);
> + return 0;
> + }

As far as I can see phy_init() and phy_exit() already keep reference
count on the initialization and you only call this function from
phy_ops->init, so you should be able to drop this.

[..]
> +
> +/* PHY Initialization */
> +static int qcom_qmp_phy_init(struct phy *phy)
> +{
[..]
> + /* phy power down delay; given in PCIE phy programming guide only */
> + if (qphy->cfg->type == PHY_TYPE_PCIE)

Rather than basing this off "is this pcie" it's preferred if you have a
bool power_down_delay; (or optionally carrying the timeout value) to
control this.

> + usleep_range(POWER_DOWN_DELAY_US_MIN, POWER_DOWN_DELAY_US_MAX);
> +
> + /* start SerDes and Phy-Coding-Sublayer */
> + qphy_setbits(pcs + QPHY_START_CTRL, cfg->start_ctrl);
> +
> + /* Pull PHY out of reset state */
> + qphy_clrbits(pcs + QPHY_SW_RESET, SW_RESET);
> +
> + status = pcs + cfg->regs[QPHY_PCS_READY_STATUS];
> + mask = cfg->mask_pcs_ready;
> +
> + ret = !mask ? 0 : readl_poll_timeout(status, val, !(val & mask), 1,
> + PHY_INIT_COMPLETE_TIMEOUT);

I presume it's not okay to read the status register even once for pcie?
If it is you can skip the conditional as !(val & 0) will break the poll
after the first read.

[..]
> +static int qcom_qmp_phy_exit(struct phy *phy)
> +{
[..]
> +}
> +
> +

Extra blank line

> +static int qcom_qmp_phy_regulator_init(struct device *dev)
[..]
> +static
> +struct qmp_phy_desc *qcom_qmp_phy_create(struct platform_device *pdev, int 
> id)
> +{
[..]
> + phy_desc->pipe_clk = devm_clk_get(dev, prop_name);
> + if (IS_ERR(phy_desc->pipe_clk)) {
> + if (qphy->cfg->type == PHY_TYPE_PCIE ||
> + qphy->cfg->type == PHY_TYPE_USB3) {

Is this check adding any value?

> + ret = PTR_ERR(phy_desc->pipe_clk);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev,
> + "failed to get lane%d pipe_clk, %d\n",
> + id, ret);
> + return ERR_PTR(ret);
> + }
> + phy_desc->pipe_clk = NULL;

Regards,
Bjorn

Re: [PATCH v3 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

[Bjorn Andersson]

On Tue 20 Dec 09:03 PST 2016, Vivek Gautam wrote:

> diff --git a/drivers/phy/phy-qcom-qmp.c b/drivers/phy/phy-qcom-qmp.c
[..]
> +static int qcom_qmp_phy_poweron(struct phy *phy)
[..]
> +
> +err3:

Rather than naming your labels errX, it's idiomatic to give them
descriptive names, e.g. "disable_ref_clk" here.

> + clk_disable_unprepare(qphy->ref_clk);
> +err2:
> + regulator_disable(qphy->vddp_ref_clk);
> +err1:
> + regulator_disable(qphy->vdda_pll);
> +err:
> + regulator_disable(qphy->vdda_phy);
> + return ret;
> +}
[..]
> +static int qcom_qmp_phy_com_init(struct qcom_qmp_phy *qphy)
> +{
> + const struct qmp_phy_cfg *cfg = qphy->cfg;
> + void __iomem *serdes = qphy->serdes;
> + int ret;
> +
> + mutex_lock(>phy_mutex);
> + if (qphy->init_count++) {
> + mutex_unlock(>phy_mutex);
> + return 0;
> + }

As far as I can see phy_init() and phy_exit() already keep reference
count on the initialization and you only call this function from
phy_ops->init, so you should be able to drop this.

[..]
> +
> +/* PHY Initialization */
> +static int qcom_qmp_phy_init(struct phy *phy)
> +{
[..]
> + /* phy power down delay; given in PCIE phy programming guide only */
> + if (qphy->cfg->type == PHY_TYPE_PCIE)

Rather than basing this off "is this pcie" it's preferred if you have a
bool power_down_delay; (or optionally carrying the timeout value) to
control this.

> + usleep_range(POWER_DOWN_DELAY_US_MIN, POWER_DOWN_DELAY_US_MAX);
> +
> + /* start SerDes and Phy-Coding-Sublayer */
> + qphy_setbits(pcs + QPHY_START_CTRL, cfg->start_ctrl);
> +
> + /* Pull PHY out of reset state */
> + qphy_clrbits(pcs + QPHY_SW_RESET, SW_RESET);
> +
> + status = pcs + cfg->regs[QPHY_PCS_READY_STATUS];
> + mask = cfg->mask_pcs_ready;
> +
> + ret = !mask ? 0 : readl_poll_timeout(status, val, !(val & mask), 1,
> + PHY_INIT_COMPLETE_TIMEOUT);

I presume it's not okay to read the status register even once for pcie?
If it is you can skip the conditional as !(val & 0) will break the poll
after the first read.

[..]
> +static int qcom_qmp_phy_exit(struct phy *phy)
> +{
[..]
> +}
> +
> +

Extra blank line

> +static int qcom_qmp_phy_regulator_init(struct device *dev)
[..]
> +static
> +struct qmp_phy_desc *qcom_qmp_phy_create(struct platform_device *pdev, int 
> id)
> +{
[..]
> + phy_desc->pipe_clk = devm_clk_get(dev, prop_name);
> + if (IS_ERR(phy_desc->pipe_clk)) {
> + if (qphy->cfg->type == PHY_TYPE_PCIE ||
> + qphy->cfg->type == PHY_TYPE_USB3) {

Is this check adding any value?

> + ret = PTR_ERR(phy_desc->pipe_clk);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev,
> + "failed to get lane%d pipe_clk, %d\n",
> + id, ret);
> + return ERR_PTR(ret);
> + }
> + phy_desc->pipe_clk = NULL;

Regards,
Bjorn

[PATCH v2 01/2] rtl8192u: r8192U:- Do not use 'asm/io.h' directly, use 'linux/io.h'.

[Arvind Yadav]

'commit 2584cf83578c ("arch, drivers: don't
include  directly, use  instead")'
Make uniform definition of ioremap, ioremap_wc, ioremap_wt and
ioremap_cache, tree-wide.

Signed-off-by: Arvind Yadav 
---
 drivers/staging/rtl8192u/r8192U.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 0b7b04e..c078659 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -34,7 +34,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include "ieee80211/ieee80211.h"
 
 #define RTL8192U
-- 
1.9.1

Re: [PATCH 2/2] ocfs2: fix deadlocks when taking inode lock at vfs entry points

[Eric Ren]

On 01/06/2017 02:09 PM, Joseph Qi wrote:

Hi Eric,


On 17/1/5 23:31, Eric Ren wrote:

Commit 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()")
results in a deadlock, as the author "Tariq Saeed" realized shortly
after the patch was merged. The discussion happened here
(https://oss.oracle.com/pipermail/ocfs2-devel/2015-September/011085.html).

The reason why taking cluster inode lock at vfs entry points opens up
a self deadlock window, is explained in the previous patch of this
series.

So far, we have seen two different code paths that have this issue.
1. do_sys_open
  may_open
   inode_permission
ocfs2_permission
 ocfs2_inode_lock() <=== take PR
  generic_permission
   get_acl
ocfs2_iop_get_acl
 ocfs2_inode_lock() <=== take PR
2. fchmod|fchmodat
 chmod_common
  notify_change
   ocfs2_setattr <=== take EX
posix_acl_chmod
 get_acl
  ocfs2_iop_get_acl <=== take PR
 ocfs2_iop_set_acl <=== take EX

Fixes them by adding the tracking logic (in the previous patch) for
these funcs above, ocfs2_permission(), ocfs2_iop_[set|get]_acl(),
ocfs2_setattr().

As described cases above, shall we just add the tracking logic only for 
set/get_acl()?


The idea is to detect recursive locking on the running task stack. Take case 1) for example 
if ocfs2_permisssion()

is not changed:

ocfs2_permission() <=== take PR, ocfs2_holder is not added
   ocfs2_iop_get_acl <=== still take PR, because there is no lock holder on the 
tracking list

Thanks for your review;-)
Eric



Thanks,
Joseph


Signed-off-by: Eric Ren 
---
  fs/ocfs2/acl.c  | 39 ++-
  fs/ocfs2/file.c | 44 ++--
  2 files changed, 68 insertions(+), 15 deletions(-)

diff --git a/fs/ocfs2/acl.c b/fs/ocfs2/acl.c
index bed1fcb..c539890 100644
--- a/fs/ocfs2/acl.c
+++ b/fs/ocfs2/acl.c
@@ -284,16 +284,31 @@ int ocfs2_iop_set_acl(struct inode *inode, struct posix_acl *acl, 
int type)

  {
  struct buffer_head *bh = NULL;
  int status = 0;
-
-status = ocfs2_inode_lock(inode, , 1);
+int arg_flags = 0, has_locked;
+struct ocfs2_holder oh;
+struct ocfs2_lock_res *lockres;
+
+lockres = _I(inode)->ip_inode_lockres;
+has_locked = (ocfs2_is_locked_by_me(lockres) != NULL);
+if (has_locked)
+arg_flags = OCFS2_META_LOCK_GETBH;
+status = ocfs2_inode_lock_full(inode, , 1, arg_flags);
  if (status < 0) {
  if (status != -ENOENT)
  mlog_errno(status);
  return status;
  }
+if (!has_locked)
+ocfs2_add_holder(lockres, );
+
  status = ocfs2_set_acl(NULL, inode, bh, type, acl, NULL, NULL);
-ocfs2_inode_unlock(inode, 1);
+
+if (!has_locked) {
+ocfs2_remove_holder(lockres, );
+ocfs2_inode_unlock(inode, 1);
+}
  brelse(bh);
+
  return status;
  }
  @@ -303,21 +318,35 @@ struct posix_acl *ocfs2_iop_get_acl(struct inode 
*inode, int type)
  struct buffer_head *di_bh = NULL;
  struct posix_acl *acl;
  int ret;
+int arg_flags = 0, has_locked;
+struct ocfs2_holder oh;
+struct ocfs2_lock_res *lockres;
osb = OCFS2_SB(inode->i_sb);
  if (!(osb->s_mount_opt & OCFS2_MOUNT_POSIX_ACL))
  return NULL;
-ret = ocfs2_inode_lock(inode, _bh, 0);
+
+lockres = _I(inode)->ip_inode_lockres;
+has_locked = (ocfs2_is_locked_by_me(lockres) != NULL);
+if (has_locked)
+arg_flags = OCFS2_META_LOCK_GETBH;
+ret = ocfs2_inode_lock_full(inode, _bh, 0, arg_flags);
  if (ret < 0) {
  if (ret != -ENOENT)
  mlog_errno(ret);
  return ERR_PTR(ret);
  }
+if (!has_locked)
+ocfs2_add_holder(lockres, );
acl = ocfs2_get_acl_nolock(inode, type, di_bh);
  -ocfs2_inode_unlock(inode, 0);
+if (!has_locked) {
+ocfs2_remove_holder(lockres, );
+ocfs2_inode_unlock(inode, 0);
+}
  brelse(di_bh);
+
  return acl;
  }
  diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c
index c488965..62be75d 100644
--- a/fs/ocfs2/file.c
+++ b/fs/ocfs2/file.c
@@ -1138,6 +1138,9 @@ int ocfs2_setattr(struct dentry *dentry, struct iattr 
*attr)
  handle_t *handle = NULL;
  struct dquot *transfer_to[MAXQUOTAS] = { };
  int qtype;
+int arg_flags = 0, had_lock;
+struct ocfs2_holder oh;
+struct ocfs2_lock_res *lockres;
trace_ocfs2_setattr(inode, dentry,
  (unsigned long long)OCFS2_I(inode)->ip_blkno,
@@ -1173,13 +1176,20 @@ int ocfs2_setattr(struct dentry *dentry, struct iattr 
*attr)
  }
  }
  -status = ocfs2_inode_lock(inode, , 1);
+lockres = _I(inode)->ip_inode_lockres;
+had_lock = (ocfs2_is_locked_by_me(lockres) != NULL);
+if (had_lock)
+arg_flags = OCFS2_META_LOCK_GETBH;
+status = ocfs2_inode_lock_full(inode, , 1, arg_flags);
  if (status < 0) {
  if (status != -ENOENT)
  

Re: [PATCH 2/2] ocfs2: fix deadlocks when taking inode lock at vfs entry points

[Eric Ren]

On 01/06/2017 02:09 PM, Joseph Qi wrote:

Hi Eric,


On 17/1/5 23:31, Eric Ren wrote:

Commit 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()")
results in a deadlock, as the author "Tariq Saeed" realized shortly
after the patch was merged. The discussion happened here
(https://oss.oracle.com/pipermail/ocfs2-devel/2015-September/011085.html).

The reason why taking cluster inode lock at vfs entry points opens up
a self deadlock window, is explained in the previous patch of this
series.

So far, we have seen two different code paths that have this issue.
1. do_sys_open
  may_open
   inode_permission
ocfs2_permission
 ocfs2_inode_lock() <=== take PR
  generic_permission
   get_acl
ocfs2_iop_get_acl
 ocfs2_inode_lock() <=== take PR
2. fchmod|fchmodat
 chmod_common
  notify_change
   ocfs2_setattr <=== take EX
posix_acl_chmod
 get_acl
  ocfs2_iop_get_acl <=== take PR
 ocfs2_iop_set_acl <=== take EX

Fixes them by adding the tracking logic (in the previous patch) for
these funcs above, ocfs2_permission(), ocfs2_iop_[set|get]_acl(),
ocfs2_setattr().

As described cases above, shall we just add the tracking logic only for 
set/get_acl()?


The idea is to detect recursive locking on the running task stack. Take case 1) for example 
if ocfs2_permisssion()

is not changed:

ocfs2_permission() <=== take PR, ocfs2_holder is not added
   ocfs2_iop_get_acl <=== still take PR, because there is no lock holder on the 
tracking list

Thanks for your review;-)
Eric



Thanks,
Joseph


Signed-off-by: Eric Ren 
---
  fs/ocfs2/acl.c  | 39 ++-
  fs/ocfs2/file.c | 44 ++--
  2 files changed, 68 insertions(+), 15 deletions(-)

diff --git a/fs/ocfs2/acl.c b/fs/ocfs2/acl.c
index bed1fcb..c539890 100644
--- a/fs/ocfs2/acl.c
+++ b/fs/ocfs2/acl.c
@@ -284,16 +284,31 @@ int ocfs2_iop_set_acl(struct inode *inode, struct posix_acl *acl, 
int type)

  {
  struct buffer_head *bh = NULL;
  int status = 0;
-
-status = ocfs2_inode_lock(inode, , 1);
+int arg_flags = 0, has_locked;
+struct ocfs2_holder oh;
+struct ocfs2_lock_res *lockres;
+
+lockres = _I(inode)->ip_inode_lockres;
+has_locked = (ocfs2_is_locked_by_me(lockres) != NULL);
+if (has_locked)
+arg_flags = OCFS2_META_LOCK_GETBH;
+status = ocfs2_inode_lock_full(inode, , 1, arg_flags);
  if (status < 0) {
  if (status != -ENOENT)
  mlog_errno(status);
  return status;
  }
+if (!has_locked)
+ocfs2_add_holder(lockres, );
+
  status = ocfs2_set_acl(NULL, inode, bh, type, acl, NULL, NULL);
-ocfs2_inode_unlock(inode, 1);
+
+if (!has_locked) {
+ocfs2_remove_holder(lockres, );
+ocfs2_inode_unlock(inode, 1);
+}
  brelse(bh);
+
  return status;
  }
  @@ -303,21 +318,35 @@ struct posix_acl *ocfs2_iop_get_acl(struct inode 
*inode, int type)
  struct buffer_head *di_bh = NULL;
  struct posix_acl *acl;
  int ret;
+int arg_flags = 0, has_locked;
+struct ocfs2_holder oh;
+struct ocfs2_lock_res *lockres;
osb = OCFS2_SB(inode->i_sb);
  if (!(osb->s_mount_opt & OCFS2_MOUNT_POSIX_ACL))
  return NULL;
-ret = ocfs2_inode_lock(inode, _bh, 0);
+
+lockres = _I(inode)->ip_inode_lockres;
+has_locked = (ocfs2_is_locked_by_me(lockres) != NULL);
+if (has_locked)
+arg_flags = OCFS2_META_LOCK_GETBH;
+ret = ocfs2_inode_lock_full(inode, _bh, 0, arg_flags);
  if (ret < 0) {
  if (ret != -ENOENT)
  mlog_errno(ret);
  return ERR_PTR(ret);
  }
+if (!has_locked)
+ocfs2_add_holder(lockres, );
acl = ocfs2_get_acl_nolock(inode, type, di_bh);
  -ocfs2_inode_unlock(inode, 0);
+if (!has_locked) {
+ocfs2_remove_holder(lockres, );
+ocfs2_inode_unlock(inode, 0);
+}
  brelse(di_bh);
+
  return acl;
  }
  diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c
index c488965..62be75d 100644
--- a/fs/ocfs2/file.c
+++ b/fs/ocfs2/file.c
@@ -1138,6 +1138,9 @@ int ocfs2_setattr(struct dentry *dentry, struct iattr 
*attr)
  handle_t *handle = NULL;
  struct dquot *transfer_to[MAXQUOTAS] = { };
  int qtype;
+int arg_flags = 0, had_lock;
+struct ocfs2_holder oh;
+struct ocfs2_lock_res *lockres;
trace_ocfs2_setattr(inode, dentry,
  (unsigned long long)OCFS2_I(inode)->ip_blkno,
@@ -1173,13 +1176,20 @@ int ocfs2_setattr(struct dentry *dentry, struct iattr 
*attr)
  }
  }
  -status = ocfs2_inode_lock(inode, , 1);
+lockres = _I(inode)->ip_inode_lockres;
+had_lock = (ocfs2_is_locked_by_me(lockres) != NULL);
+if (had_lock)
+arg_flags = OCFS2_META_LOCK_GETBH;
+status = ocfs2_inode_lock_full(inode, , 1, arg_flags);
  if (status < 0) {
  if (status != -ENOENT)
  

[PATCH v2 01/2] rtl8192u: r8192U:- Do not use 'asm/io.h' directly, use 'linux/io.h'.

[Arvind Yadav]

'commit 2584cf83578c ("arch, drivers: don't
include  directly, use  instead")'
Make uniform definition of ioremap, ioremap_wc, ioremap_wt and
ioremap_cache, tree-wide.

Signed-off-by: Arvind Yadav 
---
 drivers/staging/rtl8192u/r8192U.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 0b7b04e..c078659 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -34,7 +34,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include "ieee80211/ieee80211.h"
 
 #define RTL8192U
-- 
1.9.1

Re: [PATCH] drm/via: use get_user_pages_unlocked()

[Lorenzo Stoakes]

On 3 January 2017 at 20:23, Lorenzo Stoakes  wrote:
> Hi All,
>
> Just a gentle ping on this one :)
>
> Cheers, Lorenzo
>
> On 1 November 2016 at 19:43, Lorenzo Stoakes  wrote:
>> Moving from get_user_pages() to get_user_pages_unlocked() simplifies the code
>> and takes advantage of VM_FAULT_RETRY functionality when faulting in pages.
>>
>> Signed-off-by: Lorenzo Stoakes 
>> ---
>>  drivers/gpu/drm/via/via_dmablit.c | 10 +++---
>>  1 file changed, 3 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/via/via_dmablit.c 
>> b/drivers/gpu/drm/via/via_dmablit.c
>> index 1a3ad76..98aae98 100644
>> --- a/drivers/gpu/drm/via/via_dmablit.c
>> +++ b/drivers/gpu/drm/via/via_dmablit.c
>> @@ -238,13 +238,9 @@ via_lock_all_dma_pages(drm_via_sg_info_t *vsg,  
>> drm_via_dmablit_t *xfer)
>> vsg->pages = vzalloc(sizeof(struct page *) * vsg->num_pages);
>> if (NULL == vsg->pages)
>> return -ENOMEM;
>> -   down_read(>mm->mmap_sem);
>> -   ret = get_user_pages((unsigned long)xfer->mem_addr,
>> -vsg->num_pages,
>> -(vsg->direction == DMA_FROM_DEVICE) ? 
>> FOLL_WRITE : 0,
>> -vsg->pages, NULL);
>> -
>> -   up_read(>mm->mmap_sem);
>> +   ret = get_user_pages_unlocked((unsigned long)xfer->mem_addr,
>> +   vsg->num_pages, vsg->pages,
>> +   (vsg->direction == DMA_FROM_DEVICE) ? FOLL_WRITE : 
>> 0);
>> if (ret != vsg->num_pages) {
>> if (ret < 0)
>> return ret;
>> --
>> 2.10.2
>>

Adding Andrew, as this may be another less active corner of the corner, thanks!

-- 
Lorenzo Stoakes
https://ljs.io

Re: [PATCH v3 2/5] arm64: dts: exynos: make tm2 and tm2e independent from each other

[Krzysztof Kozlowski]

On Fri, Jan 06, 2017 at 12:59:06PM +0900, Jaechul Lee wrote:
> From: Andi Shyti 
> 
> Currently tm2e dts includes tm2 but there are some differences
> between the two boards and tm2 has some properties that tm2e
> doesn't have.
> 
> That's why it's important to keep the two dts files independent
> and put all the commonalities in a tm2-common.dtsi file.
> 
> At the current status the only two differences between the two
> dts files (besides the board name) are ldo31 and ldo38.
> 
> Signed-off-by: Andi Shyti 
> Signed-off-by: Jaechul Lee 
> ---
>  .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 1118 +++
>  arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  | 1153 
> +---

Like talking to a wall. Without any feedback. If my instructions were
wrong (and it is not possible to detect rename) then please say it (you
can add personal comments after separator ---).

As of now because it is third time without any explanation: NACK.

Best regards,
Krzysztof

>  arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts |   22 +-
>  3 files changed, 1163 insertions(+), 1130 deletions(-)
>  create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>  rewrite arch/arm64/boot/dts/exynos/exynos5433-tm2.dts (98%)
> 
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
> b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> new file mode 100644
> index 000..c43f9a3
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> @@ -0,0 +1,1118 @@
> +/*
> + * SAMSUNG Exynos5433 TM2 board device tree source
> + *
> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
> + *
> + * Common device tree source file for Samsung's TM2 and TM2E boards
> + * which are based on Samsung Exynos5433 SoC.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/dts-v1/;
> +#include "exynos5433.dtsi"
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/ {
> + model = "Samsung TM2 board";
> + compatible = "samsung,tm2", "samsung,exynos5433";
> +
> + aliases {
> + gsc0 = _0;
> + gsc1 = _1;
> + gsc2 = _2;
> + pinctrl0 = _alive;
> + pinctrl1 = _aud;
> + pinctrl2 = _cpif;
> + pinctrl3 = _ese;
> + pinctrl4 = _finger;
> + pinctrl5 = _fsys;
> + pinctrl6 = _imem;
> + pinctrl7 = _nfc;
> + pinctrl8 = _peric;
> + pinctrl9 = _touch;
> + serial0 = _0;
> + serial1 = _1;
> + serial2 = _2;
> + serial3 = _3;
> + spi0 = _0;
> + spi1 = _1;
> + spi2 = _2;
> + spi3 = _3;
> + spi4 = _4;
> + mshc0 = _0;
> + mshc2 = _2;
> + };
> +
> + chosen {
> + stdout-path = _1;
> + };
> +
> + memory@2000 {
> + device_type = "memory";
> + reg = <0x0 0x2000 0x0 0xc000>;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + power-key {
> + gpios = < 7 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + label = "power key";
> + debounce-interval = <10>;
> + };
> +
> + volume-up-key {
> + gpios = < 0 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + label = "volume-up key";
> + debounce-interval = <10>;
> + };
> +
> + volume-down-key {
> + gpios = < 1 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + label = "volume-down key";
> + debounce-interval = <10>;
> + };
> +
> + homepage-key {
> + gpios = < 3 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + label = "homepage key";
> + debounce-interval = <10>;
> + };
> + };
> +
> + i2c_max98504: i2c-gpio-0 {
> + compatible = "i2c-gpio";
> + gpios = < 1 GPIO_ACTIVE_HIGH /* SPK_AMP_SDA */
> +   0 GPIO_ACTIVE_HIGH /* SPK_AMP_SCL */ >;
> + i2c-gpio,delay-us = <2>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + max98504: max98504@31 {
> + compatible = "maxim,max98504";
> + reg = <0x31>;
> + maxim,rx-path = <1>;
> + maxim,tx-path = <1>;
> + maxim,tx-channel-mask = <3>;
> + maxim,tx-channel-source = <2>;
> + 

Re: [PATCH] drm/via: use get_user_pages_unlocked()

[Lorenzo Stoakes]

On 3 January 2017 at 20:23, Lorenzo Stoakes  wrote:
> Hi All,
>
> Just a gentle ping on this one :)
>
> Cheers, Lorenzo
>
> On 1 November 2016 at 19:43, Lorenzo Stoakes  wrote:
>> Moving from get_user_pages() to get_user_pages_unlocked() simplifies the code
>> and takes advantage of VM_FAULT_RETRY functionality when faulting in pages.
>>
>> Signed-off-by: Lorenzo Stoakes 
>> ---
>>  drivers/gpu/drm/via/via_dmablit.c | 10 +++---
>>  1 file changed, 3 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/via/via_dmablit.c 
>> b/drivers/gpu/drm/via/via_dmablit.c
>> index 1a3ad76..98aae98 100644
>> --- a/drivers/gpu/drm/via/via_dmablit.c
>> +++ b/drivers/gpu/drm/via/via_dmablit.c
>> @@ -238,13 +238,9 @@ via_lock_all_dma_pages(drm_via_sg_info_t *vsg,  
>> drm_via_dmablit_t *xfer)
>> vsg->pages = vzalloc(sizeof(struct page *) * vsg->num_pages);
>> if (NULL == vsg->pages)
>> return -ENOMEM;
>> -   down_read(>mm->mmap_sem);
>> -   ret = get_user_pages((unsigned long)xfer->mem_addr,
>> -vsg->num_pages,
>> -(vsg->direction == DMA_FROM_DEVICE) ? 
>> FOLL_WRITE : 0,
>> -vsg->pages, NULL);
>> -
>> -   up_read(>mm->mmap_sem);
>> +   ret = get_user_pages_unlocked((unsigned long)xfer->mem_addr,
>> +   vsg->num_pages, vsg->pages,
>> +   (vsg->direction == DMA_FROM_DEVICE) ? FOLL_WRITE : 
>> 0);
>> if (ret != vsg->num_pages) {
>> if (ret < 0)
>> return ret;
>> --
>> 2.10.2
>>

Adding Andrew, as this may be another less active corner of the corner, thanks!

-- 
Lorenzo Stoakes
https://ljs.io

Re: [PATCH v3 2/5] arm64: dts: exynos: make tm2 and tm2e independent from each other

[Krzysztof Kozlowski]

On Fri, Jan 06, 2017 at 12:59:06PM +0900, Jaechul Lee wrote:
> From: Andi Shyti 
> 
> Currently tm2e dts includes tm2 but there are some differences
> between the two boards and tm2 has some properties that tm2e
> doesn't have.
> 
> That's why it's important to keep the two dts files independent
> and put all the commonalities in a tm2-common.dtsi file.
> 
> At the current status the only two differences between the two
> dts files (besides the board name) are ldo31 and ldo38.
> 
> Signed-off-by: Andi Shyti 
> Signed-off-by: Jaechul Lee 
> ---
>  .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 1118 +++
>  arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  | 1153 
> +---

Like talking to a wall. Without any feedback. If my instructions were
wrong (and it is not possible to detect rename) then please say it (you
can add personal comments after separator ---).

As of now because it is third time without any explanation: NACK.

Best regards,
Krzysztof

>  arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts |   22 +-
>  3 files changed, 1163 insertions(+), 1130 deletions(-)
>  create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>  rewrite arch/arm64/boot/dts/exynos/exynos5433-tm2.dts (98%)
> 
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
> b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> new file mode 100644
> index 000..c43f9a3
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> @@ -0,0 +1,1118 @@
> +/*
> + * SAMSUNG Exynos5433 TM2 board device tree source
> + *
> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
> + *
> + * Common device tree source file for Samsung's TM2 and TM2E boards
> + * which are based on Samsung Exynos5433 SoC.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/dts-v1/;
> +#include "exynos5433.dtsi"
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/ {
> + model = "Samsung TM2 board";
> + compatible = "samsung,tm2", "samsung,exynos5433";
> +
> + aliases {
> + gsc0 = _0;
> + gsc1 = _1;
> + gsc2 = _2;
> + pinctrl0 = _alive;
> + pinctrl1 = _aud;
> + pinctrl2 = _cpif;
> + pinctrl3 = _ese;
> + pinctrl4 = _finger;
> + pinctrl5 = _fsys;
> + pinctrl6 = _imem;
> + pinctrl7 = _nfc;
> + pinctrl8 = _peric;
> + pinctrl9 = _touch;
> + serial0 = _0;
> + serial1 = _1;
> + serial2 = _2;
> + serial3 = _3;
> + spi0 = _0;
> + spi1 = _1;
> + spi2 = _2;
> + spi3 = _3;
> + spi4 = _4;
> + mshc0 = _0;
> + mshc2 = _2;
> + };
> +
> + chosen {
> + stdout-path = _1;
> + };
> +
> + memory@2000 {
> + device_type = "memory";
> + reg = <0x0 0x2000 0x0 0xc000>;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + power-key {
> + gpios = < 7 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + label = "power key";
> + debounce-interval = <10>;
> + };
> +
> + volume-up-key {
> + gpios = < 0 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + label = "volume-up key";
> + debounce-interval = <10>;
> + };
> +
> + volume-down-key {
> + gpios = < 1 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + label = "volume-down key";
> + debounce-interval = <10>;
> + };
> +
> + homepage-key {
> + gpios = < 3 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + label = "homepage key";
> + debounce-interval = <10>;
> + };
> + };
> +
> + i2c_max98504: i2c-gpio-0 {
> + compatible = "i2c-gpio";
> + gpios = < 1 GPIO_ACTIVE_HIGH /* SPK_AMP_SDA */
> +   0 GPIO_ACTIVE_HIGH /* SPK_AMP_SCL */ >;
> + i2c-gpio,delay-us = <2>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + max98504: max98504@31 {
> + compatible = "maxim,max98504";
> + reg = <0x31>;
> + maxim,rx-path = <1>;
> + maxim,tx-path = <1>;
> + maxim,tx-channel-mask = <3>;
> + maxim,tx-channel-source = <2>;
> + };
> + };
> +
> + sound {
> + compatible = 

Re: [RFC 1/1] Changes to support the driver for platform device registration

[Raviteja Garimella]

Hi Florian,

On Thu, Jan 5, 2017 at 11:13 PM, Florian Fainelli  wrote:
> On 01/05/2017 12:23 AM, Raviteja Garimella wrote:
>> -- Add OF based platform device registration
>> -- Modify debug prints to be compatible with both pci and platform devices
>> -- Add members to 'struct udc' for extcon and phy support
>> -- Add checks to not process repeated calls to udc connect and
>>disconnect routines
>> -- Kconfig changes
>
> What you are doing in this patch is all well and good, but since you are
> listing these changes, that means we should see 4/5 patches submitted to
> this driver each one doing what you have as a bullet point.
>
> Since you are adding Device Tree probing support to the driver, you also
> need to create a proper binding document which describes the properties
> and nodes.

I will split this patch into multiple patches, and also create the
binding document.
Thanks. I will wait a bit for any other comments.

Ravi

>
> Thank you
> --
> Florian

Re: [RFC 1/1] Changes to support the driver for platform device registration

[Raviteja Garimella]

Hi Florian,

On Thu, Jan 5, 2017 at 11:13 PM, Florian Fainelli  wrote:
> On 01/05/2017 12:23 AM, Raviteja Garimella wrote:
>> -- Add OF based platform device registration
>> -- Modify debug prints to be compatible with both pci and platform devices
>> -- Add members to 'struct udc' for extcon and phy support
>> -- Add checks to not process repeated calls to udc connect and
>>disconnect routines
>> -- Kconfig changes
>
> What you are doing in this patch is all well and good, but since you are
> listing these changes, that means we should see 4/5 patches submitted to
> this driver each one doing what you have as a bullet point.
>
> Since you are adding Device Tree probing support to the driver, you also
> need to create a proper binding document which describes the properties
> and nodes.

I will split this patch into multiple patches, and also create the
binding document.
Thanks. I will wait a bit for any other comments.

Ravi

>
> Thank you
> --
> Florian

[PATCH 1/3] ARM: at91: flush the L2 cache before entering cpu idle

[Wenyou Yang]

For the SoCs such as SAMA5D2 and SAMA5D4 which have L2 cache,
flush the L2 cache first before entering the cpu idle.

Signed-off-by: Wenyou Yang 
---

 arch/arm/mach-at91/pm.c   | 19 +++
 drivers/memory/atmel-sdramc.c |  1 +
 2 files changed, 20 insertions(+)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index b4332b727e9c..1a60dede1a01 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -289,6 +289,24 @@ static void at91_ddr_standby(void)
at91_ramc_write(1, AT91_DDRSDRC_LPR, saved_lpr1);
 }
 
+static void at91_ddr_cache_standby(void)
+{
+   u32 saved_lpr;
+
+   flush_cache_all();
+   outer_disable();
+
+   saved_lpr = at91_ramc_read(0, AT91_DDRSDRC_LPR);
+   at91_ramc_write(0, AT91_DDRSDRC_LPR, (saved_lpr &
+   (~AT91_DDRSDRC_LPCB)) | AT91_DDRSDRC_LPCB_SELF_REFRESH);
+
+   cpu_do_idle();
+
+   at91_ramc_write(0, AT91_DDRSDRC_LPR, saved_lpr);
+
+   outer_resume();
+}
+
 /* We manage both DDRAM/SDRAM controllers, we need more than one value to
  * remember.
  */
@@ -324,6 +342,7 @@ static const struct of_device_id const ramc_ids[] 
__initconst = {
{ .compatible = "atmel,at91sam9260-sdramc", .data = 
at91sam9_sdram_standby },
{ .compatible = "atmel,at91sam9g45-ddramc", .data = at91_ddr_standby },
{ .compatible = "atmel,sama5d3-ddramc", .data = at91_ddr_standby },
+   { .compatible = "atmel,sama5d4-ddramc", .data = at91_ddr_cache_standby 
},
{ /*sentinel*/ }
 };
 
diff --git a/drivers/memory/atmel-sdramc.c b/drivers/memory/atmel-sdramc.c
index b418b39af180..7e5c5c6c1348 100644
--- a/drivers/memory/atmel-sdramc.c
+++ b/drivers/memory/atmel-sdramc.c
@@ -48,6 +48,7 @@ static const struct of_device_id atmel_ramc_of_match[] = {
{ .compatible = "atmel,at91sam9260-sdramc", .data = _caps, },
{ .compatible = "atmel,at91sam9g45-ddramc", .data = _caps, 
},
{ .compatible = "atmel,sama5d3-ddramc", .data = _caps, },
+   { .compatible = "atmel,sama5d4-ddramc", .data = _caps, },
{},
 };
 
-- 
2.11.0

[PATCH 1/3] ARM: at91: flush the L2 cache before entering cpu idle

[Wenyou Yang]

For the SoCs such as SAMA5D2 and SAMA5D4 which have L2 cache,
flush the L2 cache first before entering the cpu idle.

Signed-off-by: Wenyou Yang 
---

 arch/arm/mach-at91/pm.c   | 19 +++
 drivers/memory/atmel-sdramc.c |  1 +
 2 files changed, 20 insertions(+)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index b4332b727e9c..1a60dede1a01 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -289,6 +289,24 @@ static void at91_ddr_standby(void)
at91_ramc_write(1, AT91_DDRSDRC_LPR, saved_lpr1);
 }
 
+static void at91_ddr_cache_standby(void)
+{
+   u32 saved_lpr;
+
+   flush_cache_all();
+   outer_disable();
+
+   saved_lpr = at91_ramc_read(0, AT91_DDRSDRC_LPR);
+   at91_ramc_write(0, AT91_DDRSDRC_LPR, (saved_lpr &
+   (~AT91_DDRSDRC_LPCB)) | AT91_DDRSDRC_LPCB_SELF_REFRESH);
+
+   cpu_do_idle();
+
+   at91_ramc_write(0, AT91_DDRSDRC_LPR, saved_lpr);
+
+   outer_resume();
+}
+
 /* We manage both DDRAM/SDRAM controllers, we need more than one value to
  * remember.
  */
@@ -324,6 +342,7 @@ static const struct of_device_id const ramc_ids[] 
__initconst = {
{ .compatible = "atmel,at91sam9260-sdramc", .data = 
at91sam9_sdram_standby },
{ .compatible = "atmel,at91sam9g45-ddramc", .data = at91_ddr_standby },
{ .compatible = "atmel,sama5d3-ddramc", .data = at91_ddr_standby },
+   { .compatible = "atmel,sama5d4-ddramc", .data = at91_ddr_cache_standby 
},
{ /*sentinel*/ }
 };
 
diff --git a/drivers/memory/atmel-sdramc.c b/drivers/memory/atmel-sdramc.c
index b418b39af180..7e5c5c6c1348 100644
--- a/drivers/memory/atmel-sdramc.c
+++ b/drivers/memory/atmel-sdramc.c
@@ -48,6 +48,7 @@ static const struct of_device_id atmel_ramc_of_match[] = {
{ .compatible = "atmel,at91sam9260-sdramc", .data = _caps, },
{ .compatible = "atmel,at91sam9g45-ddramc", .data = _caps, 
},
{ .compatible = "atmel,sama5d3-ddramc", .data = _caps, },
+   { .compatible = "atmel,sama5d4-ddramc", .data = _caps, },
{},
 };
 
-- 
2.11.0

[PATCH 0/3] ARM: at91: fix cpuidle crash on SAMA5D4 Xplained board

[Wenyou Yang]

Fix cpuidle crash on SAMA5D4 Xplained board when enable
CONFIG_ARM_AT91_CPUIDLE. Because some SoCs have the L2 cache,
we should flush the L2 cache before entering the cpu idle.


Wenyou Yang (3):
  ARM: at91: flush the L2 cache before entering cpu idle
  doc: binding: add new compatible for SDRAM/DDR Controller
  ARM: dts: at91: use "atmel,sama5d4-ddramc" for ramc

 Documentation/devicetree/bindings/arm/atmel-at91.txt |  1 +
 arch/arm/boot/dts/sama5d2.dtsi   |  2 +-
 arch/arm/boot/dts/sama5d4.dtsi   |  2 +-
 arch/arm/mach-at91/pm.c  | 19 +++
 drivers/memory/atmel-sdramc.c|  1 +
 5 files changed, 23 insertions(+), 2 deletions(-)

-- 
2.11.0

[PATCH 0/3] ARM: at91: fix cpuidle crash on SAMA5D4 Xplained board

[Wenyou Yang]

Fix cpuidle crash on SAMA5D4 Xplained board when enable
CONFIG_ARM_AT91_CPUIDLE. Because some SoCs have the L2 cache,
we should flush the L2 cache before entering the cpu idle.


Wenyou Yang (3):
  ARM: at91: flush the L2 cache before entering cpu idle
  doc: binding: add new compatible for SDRAM/DDR Controller
  ARM: dts: at91: use "atmel,sama5d4-ddramc" for ramc

 Documentation/devicetree/bindings/arm/atmel-at91.txt |  1 +
 arch/arm/boot/dts/sama5d2.dtsi   |  2 +-
 arch/arm/boot/dts/sama5d4.dtsi   |  2 +-
 arch/arm/mach-at91/pm.c  | 19 +++
 drivers/memory/atmel-sdramc.c|  1 +
 5 files changed, 23 insertions(+), 2 deletions(-)

-- 
2.11.0

[PATCH 2/3] doc: binding: add new compatible for SDRAM/DDR Controller

[Wenyou Yang]

Add the new compatible "atmel,sama5d4-ddramc" for the SDRAM/DDR
Controller.

Signed-off-by: Wenyou Yang 
---

 Documentation/devicetree/bindings/arm/atmel-at91.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.txt 
b/Documentation/devicetree/bindings/arm/atmel-at91.txt
index 29737b9b616e..9b5de6397666 100644
--- a/Documentation/devicetree/bindings/arm/atmel-at91.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-at91.txt
@@ -111,6 +111,7 @@ RAMC SDRAM/DDR Controller required properties:
"atmel,at91sam9260-sdramc",
"atmel,at91sam9g45-ddramc",
"atmel,sama5d3-ddramc",
+   "atmel,sama5d4-ddramc",
 - reg: Should contain registers location and length
 
 Examples:
-- 
2.11.0

Re: [PATCH v4 07/11] pwm: imx: Provide atomic PWM support for i.MX PWMv2

[Boris Brezillon]

On Thu, 5 Jan 2017 23:15:06 +0200
Andy Shevchenko  wrote:

> On Thu, Jan 5, 2017 at 11:19 AM, Boris Brezillon
>  wrote:
> > On Thu, 5 Jan 2017 10:03:47 +0100
> > Lukasz Majewski  wrote:  
> >> > /*
> >> >  * Wait for a free FIFO slot if the PWM is already
> >> > enabled, and
> >> >  * flush the FIFO if the PWM was disabled and is
> >> > about to be
> >> >  * enabled.
> >> >  */  
> 
> >> > if (cstate.enabled) {  
> 
> if (pwm_is_enabled()) ?
> 
> I think it's better to do whatever API provides to be less error prone.

Both pwm_is_enabled() and pwm_get_state()+struct pwm_state are part of
the PWM API, and I don't see how 'if (pwm_is_enabled())' is less error
prone than 'if (cstate.enabled)'.

This being said, I don't care much. It's mainly a matter of taste IMO,
so if others agree to switch to pwm_is_enabled() I'm fine with that.

> 
> >> > imx_pwm_wait_fifo_slot(chip, pwm);
> >> > } else {
> >> > ret = clk_prepare_enable(imx->clk_per);
> >> > if (ret)
> >> > return ret;  
> 
> >> if (state.enabled && !cstate.enabled)
> >>   clk_preapre_enable();  
> >
> > Yep, and that's correct.  
> 
> !pwm_is_enabled() ?
> 

[PATCH 2/3] doc: binding: add new compatible for SDRAM/DDR Controller

[Wenyou Yang]

Add the new compatible "atmel,sama5d4-ddramc" for the SDRAM/DDR
Controller.

Signed-off-by: Wenyou Yang 
---

 Documentation/devicetree/bindings/arm/atmel-at91.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.txt 
b/Documentation/devicetree/bindings/arm/atmel-at91.txt
index 29737b9b616e..9b5de6397666 100644
--- a/Documentation/devicetree/bindings/arm/atmel-at91.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-at91.txt
@@ -111,6 +111,7 @@ RAMC SDRAM/DDR Controller required properties:
"atmel,at91sam9260-sdramc",
"atmel,at91sam9g45-ddramc",
"atmel,sama5d3-ddramc",
+   "atmel,sama5d4-ddramc",
 - reg: Should contain registers location and length
 
 Examples:
-- 
2.11.0

Re: [PATCH v4 07/11] pwm: imx: Provide atomic PWM support for i.MX PWMv2

[Boris Brezillon]

On Thu, 5 Jan 2017 23:15:06 +0200
Andy Shevchenko  wrote:

> On Thu, Jan 5, 2017 at 11:19 AM, Boris Brezillon
>  wrote:
> > On Thu, 5 Jan 2017 10:03:47 +0100
> > Lukasz Majewski  wrote:  
> >> > /*
> >> >  * Wait for a free FIFO slot if the PWM is already
> >> > enabled, and
> >> >  * flush the FIFO if the PWM was disabled and is
> >> > about to be
> >> >  * enabled.
> >> >  */  
> 
> >> > if (cstate.enabled) {  
> 
> if (pwm_is_enabled()) ?
> 
> I think it's better to do whatever API provides to be less error prone.

Both pwm_is_enabled() and pwm_get_state()+struct pwm_state are part of
the PWM API, and I don't see how 'if (pwm_is_enabled())' is less error
prone than 'if (cstate.enabled)'.

This being said, I don't care much. It's mainly a matter of taste IMO,
so if others agree to switch to pwm_is_enabled() I'm fine with that.

> 
> >> > imx_pwm_wait_fifo_slot(chip, pwm);
> >> > } else {
> >> > ret = clk_prepare_enable(imx->clk_per);
> >> > if (ret)
> >> > return ret;  
> 
> >> if (state.enabled && !cstate.enabled)
> >>   clk_preapre_enable();  
> >
> > Yep, and that's correct.  
> 
> !pwm_is_enabled() ?
> 

[PATCH 3/3] ARM: dts: at91: use "atmel,sama5d4-ddramc" for ramc

[Wenyou Yang]

Use the new compatible "atmel,sama5d4-ddramc" for the ramc of
SAMA5D2 and SAMA5D4.

Signed-off-by: Wenyou Yang 
---

 arch/arm/boot/dts/sama5d2.dtsi | 2 +-
 arch/arm/boot/dts/sama5d4.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index ceb9783ff7e1..b5259d85737d 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -380,7 +380,7 @@
};
 
ramc0: ramc@f000c000 {
-   compatible = "atmel,sama5d3-ddramc";
+   compatible = "atmel,sama5d4-ddramc";
reg = <0xf000c000 0x200>;
clocks = <>, <_clk>;
clock-names = "ddrck", "mpddr";
diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
index 4f60c1b7b137..603ba986858c 100644
--- a/arch/arm/boot/dts/sama5d4.dtsi
+++ b/arch/arm/boot/dts/sama5d4.dtsi
@@ -370,7 +370,7 @@
};
 
ramc0: ramc@f001 {
-   compatible = "atmel,sama5d3-ddramc";
+   compatible = "atmel,sama5d4-ddramc";
reg = <0xf001 0x200>;
clocks = <>, <_clk>;
clock-names = "ddrck", "mpddr";
-- 
2.11.0

[PATCH 3/3] ARM: dts: at91: use "atmel,sama5d4-ddramc" for ramc

[Wenyou Yang]

Use the new compatible "atmel,sama5d4-ddramc" for the ramc of
SAMA5D2 and SAMA5D4.

Signed-off-by: Wenyou Yang 
---

 arch/arm/boot/dts/sama5d2.dtsi | 2 +-
 arch/arm/boot/dts/sama5d4.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index ceb9783ff7e1..b5259d85737d 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -380,7 +380,7 @@
};
 
ramc0: ramc@f000c000 {
-   compatible = "atmel,sama5d3-ddramc";
+   compatible = "atmel,sama5d4-ddramc";
reg = <0xf000c000 0x200>;
clocks = <>, <_clk>;
clock-names = "ddrck", "mpddr";
diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
index 4f60c1b7b137..603ba986858c 100644
--- a/arch/arm/boot/dts/sama5d4.dtsi
+++ b/arch/arm/boot/dts/sama5d4.dtsi
@@ -370,7 +370,7 @@
};
 
ramc0: ramc@f001 {
-   compatible = "atmel,sama5d3-ddramc";
+   compatible = "atmel,sama5d4-ddramc";
reg = <0xf001 0x200>;
clocks = <>, <_clk>;
clock-names = "ddrck", "mpddr";
-- 
2.11.0

Re: [PATCH v3 2/3] drivers: crypto: Add the Virtual Function driver for CPT

[George Cherian]

Hi Corentin,


On 12/21/2016 07:31 PM, Corentin Labbe wrote:

Hello

I have some comment inline

On Wed, Dec 21, 2016 at 11:56:12AM +, george.cher...@cavium.com wrote:

From: George Cherian 

Enable the CPT VF driver. CPT is the cryptographic Accelaration Unit


typo acceleration

will fix


[...]

+static inline void update_input_data(struct cpt_request_info *req_info,
+struct scatterlist *inp_sg,
+u32 nbytes, u32 *argcnt)
+{
+   req_info->req.dlen += nbytes;
+
+   while (nbytes) {
+   u32 len = min(nbytes, inp_sg->length);
+   u8 *ptr = page_address(sg_page(inp_sg)) + inp_sg->offset;


You could use sg_virt instead.

Thanks for pointing it out, Yes will replace with sg_virt.


But do you have tested your accelerator with user space data (via 
cryptodev/AF_ALG) ?
No I have tested only using in kernel applications, Not used 
cryptodev/AF_ALG

In my memory, you better use kmap() instead of this direct memory address.

[...]

+static inline u32 cvm_enc_dec(struct ablkcipher_request *req, u32 enc,
+ u32 cipher_type)
+{
+   struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(req);
+   struct cvm_enc_ctx *ctx = crypto_ablkcipher_ctx(tfm);
+   u32 key_type = AES_128_BIT;
+   struct cvm_req_ctx *rctx = ablkcipher_request_ctx(req);
+   u32 enc_iv_len = crypto_ablkcipher_ivsize(tfm);
+   struct fc_context *fctx = >fctx;
+   struct cpt_request_info *req_info = >cpt_req;
+   void *cdev = NULL;
+   u32 status = -1;


Doable but dangerous
Furthermore, cptvf_do_request return int so why use u32 ?

will fix it.


[...]

+void cvm_enc_dec_exit(struct crypto_tfm *tfm)
+{
+   return;
+}


So you could remove all reference to this function


okay

[...]

+static inline int cav_register_algs(void)
+{
+   int err = 0;
+
+   err = crypto_register_algs(algs, ARRAY_SIZE(algs));
+   if (err) {
+   pr_err("Error in aes module init %d\n", err);
+   return -1;


This is not a standard error code


okay

[...]

diff --git a/drivers/crypto/cavium/cpt/cptvf_algs.h 
b/drivers/crypto/cavium/cpt/cptvf_algs.h
new file mode 100644
index 000..fcb287b
--- /dev/null
+++ b/drivers/crypto/cavium/cpt/cptvf_algs.h

[...]

+
+u32 cptvf_do_request(void *cptvf, struct cpt_request_info *req);


latter this function is set "return int"

[...]

+static int cptvf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
+{
+   struct device *dev = >dev;
+   struct cpt_vf *cptvf;
+   interr;
+
+   cptvf = devm_kzalloc(dev, sizeof(struct cpt_vf), GFP_KERNEL);


use sizeof(*cptvf) and checkpatch


okay

[...]

+static int setup_sgio_components(struct cpt_vf *cptvf, struct buf_ptr *list,
+int buf_count, u8 *buffer)
+{
+   int ret = 0, i, j;
+   int components;
+   struct sglist_component *sg_ptr = NULL;
+   struct pci_dev *pdev = cptvf->pdev;
+
+   if (unlikely(!list)) {
+   pr_err("Input List pointer is NULL\n");
+   ret = -EFAULT;
+   return ret;


You could directly return -EFAULT and use dev_err()


okay

+   }
+
+   for (i = 0; i < buf_count; i++) {
+   if (likely(list[i].vptr)) {
+   list[i].dma_addr = dma_map_single(>dev,
+ list[i].vptr,
+ list[i].size,
+ DMA_BIDIRECTIONAL);
+   if (unlikely(dma_mapping_error(>dev,
+  list[i].dma_addr))) {
+   pr_err("DMA map kernel buffer failed for component: 
%d\n",
+  i);


Use dev_err

[...]

+   u16 g_sz_bytes = 0, s_sz_bytes = 0;
+   int ret = 0;
+   struct pci_dev *pdev = cptvf->pdev;
+
+   if (req->incnt > MAX_SG_IN_CNT || req->outcnt > MAX_SG_OUT_CNT) {
+   pr_err("Requestes SG components are higher than supported\n");


typo request and use dev_err

In all files you have some pr_x that could be better use as dev_x

okay



+   ret = -EINVAL;
+   goto  scatter_gather_clean;
+   }
+
+   /* Setup gather (input) components */
+   g_sz_bytes = ((req->incnt + 3) / 4) * sizeof(struct sglist_component);
+   info->gather_components = kzalloc((g_sz_bytes), GFP_KERNEL);


unnecessary parenthesis


+   if (!info->gather_components) {
+   ret = -ENOMEM;
+   goto  scatter_gather_clean;
+   }
+
+   ret = setup_sgio_components(cptvf, req->in,
+   req->incnt,
+   info->gather_components);
+   if (ret) {
+   pr_err("Failed to setup gather list\n");
+ 

Re: [PATCH 1/2] ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock

[Eric Ren]

On 01/06/2017 02:07 PM, Joseph Qi wrote:

Hi Eric,


On 17/1/5 23:31, Eric Ren wrote:

We are in the situation that we have to avoid recursive cluster locking,
but there is no way to check if a cluster lock has been taken by a
precess already.

Mostly, we can avoid recursive locking by writing code carefully.
However, we found that it's very hard to handle the routines that
are invoked directly by vfs code. For instance:

const struct inode_operations ocfs2_file_iops = {
 .permission = ocfs2_permission,
 .get_acl= ocfs2_iop_get_acl,
 .set_acl= ocfs2_iop_set_acl,
};

Both ocfs2_permission() and ocfs2_iop_get_acl() call ocfs2_inode_lock(PR):
do_sys_open
  may_open
   inode_permission
ocfs2_permission
 ocfs2_inode_lock() <=== first time
  generic_permission
   get_acl
ocfs2_iop_get_acl
ocfs2_inode_lock() <=== recursive one

A deadlock will occur if a remote EX request comes in between two
of ocfs2_inode_lock(). Briefly describe how the deadlock is formed:

On one hand, OCFS2_LOCK_BLOCKED flag of this lockres is set in
BAST(ocfs2_generic_handle_bast) when downconvert is started
on behalf of the remote EX lock request. Another hand, the recursive
cluster lock (the second one) will be blocked in in __ocfs2_cluster_lock()
because of OCFS2_LOCK_BLOCKED. But, the downconvert never complete, why?
because there is no chance for the first cluster lock on this node to be
unlocked - we block ourselves in the code path.

The idea to fix this issue is mostly taken from gfs2 code.
1. introduce a new field: struct ocfs2_lock_res.l_holders, to
keep track of the processes' pid  who has taken the cluster lock
of this lock resource;
2. introduce a new flag for ocfs2_inode_lock_full: OCFS2_META_LOCK_GETBH;
it means just getting back disk inode bh for us if we've got cluster lock.
3. export a helper: ocfs2_is_locked_by_me() is used to check if we
have got the cluster lock in the upper code path.

The tracking logic should be used by some of the ocfs2 vfs's callbacks,
to solve the recursive locking issue cuased by the fact that vfs routines
can call into each other.

The performance penalty of processing the holder list should only be seen
at a few cases where the tracking logic is used, such as get/set acl.

You may ask what if the first time we got a PR lock, and the second time
we want a EX lock? fortunately, this case never happens in the real world,
as far as I can see, including permission check, (get|set)_(acl|attr), and
the gfs2 code also do so.

Signed-off-by: Eric Ren 
---
  fs/ocfs2/dlmglue.c | 47 ---
  fs/ocfs2/dlmglue.h | 18 ++
  fs/ocfs2/ocfs2.h   |  1 +
  3 files changed, 63 insertions(+), 3 deletions(-)

diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
index 83d576f..500bda4 100644
--- a/fs/ocfs2/dlmglue.c
+++ b/fs/ocfs2/dlmglue.c
@@ -532,6 +532,7 @@ void ocfs2_lock_res_init_once(struct ocfs2_lock_res *res)
  init_waitqueue_head(>l_event);
  INIT_LIST_HEAD(>l_blocked_list);
  INIT_LIST_HEAD(>l_mask_waiters);
+INIT_LIST_HEAD(>l_holders);
  }
void ocfs2_inode_lock_res_init(struct ocfs2_lock_res *res,
@@ -749,6 +750,45 @@ void ocfs2_lock_res_free(struct ocfs2_lock_res *res)
  res->l_flags = 0UL;
  }
  +inline void ocfs2_add_holder(struct ocfs2_lock_res *lockres,
+   struct ocfs2_holder *oh)
+{
+INIT_LIST_HEAD(>oh_list);
+oh->oh_owner_pid =  get_pid(task_pid(current));
+
+spin_lock(>l_lock);
+list_add_tail(>oh_list, >l_holders);
+spin_unlock(>l_lock);
+}
+
+inline void ocfs2_remove_holder(struct ocfs2_lock_res *lockres,
+   struct ocfs2_holder *oh)
+{
+spin_lock(>l_lock);
+list_del(>oh_list);
+spin_unlock(>l_lock);
+
+put_pid(oh->oh_owner_pid);
+}
+
+inline struct ocfs2_holder *ocfs2_is_locked_by_me(struct ocfs2_lock_res 
*lockres)
+{
+struct ocfs2_holder *oh;
+struct pid *pid;
+
+/* look in the list of holders for one with the current task as owner */
+spin_lock(>l_lock);
+pid = task_pid(current);
+list_for_each_entry(oh, >l_holders, oh_list) {
+if (oh->oh_owner_pid == pid)
+goto out;
+}
+oh = NULL;
+out:
+spin_unlock(>l_lock);
+return oh;
+}

Since this ocfs2_holder won't be used in the caller, I suggest just return a 
bool value here.
Something like:
spin_lock();
list_for_each_entry() {
if (oh->oh_owner_pid == pid) {
spin_unlock();
return 1;
}
}
spin_unlock();
return 0;


Aha, you have the point. However, it is also reasonable to return the lock 
holder by the way.
When debugging with printk or crash, it's easy to get the pid of the holder 
without any further
analysis. So, I tend to keep it;-)

Thanks very much for your review!
Eric



Thanks,
Joseph

+
  static inline void ocfs2_inc_holders(struct ocfs2_lock_res *lockres,
   int level)
  {
@@ -2333,8 +2373,9 @@ int 

Re: [PATCH v3 2/3] drivers: crypto: Add the Virtual Function driver for CPT

[George Cherian]

Hi Corentin,


On 12/21/2016 07:31 PM, Corentin Labbe wrote:

Hello

I have some comment inline

On Wed, Dec 21, 2016 at 11:56:12AM +, george.cher...@cavium.com wrote:

From: George Cherian 

Enable the CPT VF driver. CPT is the cryptographic Accelaration Unit


typo acceleration

will fix


[...]

+static inline void update_input_data(struct cpt_request_info *req_info,
+struct scatterlist *inp_sg,
+u32 nbytes, u32 *argcnt)
+{
+   req_info->req.dlen += nbytes;
+
+   while (nbytes) {
+   u32 len = min(nbytes, inp_sg->length);
+   u8 *ptr = page_address(sg_page(inp_sg)) + inp_sg->offset;


You could use sg_virt instead.

Thanks for pointing it out, Yes will replace with sg_virt.


But do you have tested your accelerator with user space data (via 
cryptodev/AF_ALG) ?
No I have tested only using in kernel applications, Not used 
cryptodev/AF_ALG

In my memory, you better use kmap() instead of this direct memory address.

[...]

+static inline u32 cvm_enc_dec(struct ablkcipher_request *req, u32 enc,
+ u32 cipher_type)
+{
+   struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(req);
+   struct cvm_enc_ctx *ctx = crypto_ablkcipher_ctx(tfm);
+   u32 key_type = AES_128_BIT;
+   struct cvm_req_ctx *rctx = ablkcipher_request_ctx(req);
+   u32 enc_iv_len = crypto_ablkcipher_ivsize(tfm);
+   struct fc_context *fctx = >fctx;
+   struct cpt_request_info *req_info = >cpt_req;
+   void *cdev = NULL;
+   u32 status = -1;


Doable but dangerous
Furthermore, cptvf_do_request return int so why use u32 ?

will fix it.


[...]

+void cvm_enc_dec_exit(struct crypto_tfm *tfm)
+{
+   return;
+}


So you could remove all reference to this function


okay

[...]

+static inline int cav_register_algs(void)
+{
+   int err = 0;
+
+   err = crypto_register_algs(algs, ARRAY_SIZE(algs));
+   if (err) {
+   pr_err("Error in aes module init %d\n", err);
+   return -1;


This is not a standard error code


okay

[...]

diff --git a/drivers/crypto/cavium/cpt/cptvf_algs.h 
b/drivers/crypto/cavium/cpt/cptvf_algs.h
new file mode 100644
index 000..fcb287b
--- /dev/null
+++ b/drivers/crypto/cavium/cpt/cptvf_algs.h

[...]

+
+u32 cptvf_do_request(void *cptvf, struct cpt_request_info *req);


latter this function is set "return int"

[...]

+static int cptvf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
+{
+   struct device *dev = >dev;
+   struct cpt_vf *cptvf;
+   interr;
+
+   cptvf = devm_kzalloc(dev, sizeof(struct cpt_vf), GFP_KERNEL);


use sizeof(*cptvf) and checkpatch


okay

[...]

+static int setup_sgio_components(struct cpt_vf *cptvf, struct buf_ptr *list,
+int buf_count, u8 *buffer)
+{
+   int ret = 0, i, j;
+   int components;
+   struct sglist_component *sg_ptr = NULL;
+   struct pci_dev *pdev = cptvf->pdev;
+
+   if (unlikely(!list)) {
+   pr_err("Input List pointer is NULL\n");
+   ret = -EFAULT;
+   return ret;


You could directly return -EFAULT and use dev_err()


okay

+   }
+
+   for (i = 0; i < buf_count; i++) {
+   if (likely(list[i].vptr)) {
+   list[i].dma_addr = dma_map_single(>dev,
+ list[i].vptr,
+ list[i].size,
+ DMA_BIDIRECTIONAL);
+   if (unlikely(dma_mapping_error(>dev,
+  list[i].dma_addr))) {
+   pr_err("DMA map kernel buffer failed for component: 
%d\n",
+  i);


Use dev_err

[...]

+   u16 g_sz_bytes = 0, s_sz_bytes = 0;
+   int ret = 0;
+   struct pci_dev *pdev = cptvf->pdev;
+
+   if (req->incnt > MAX_SG_IN_CNT || req->outcnt > MAX_SG_OUT_CNT) {
+   pr_err("Requestes SG components are higher than supported\n");


typo request and use dev_err

In all files you have some pr_x that could be better use as dev_x

okay



+   ret = -EINVAL;
+   goto  scatter_gather_clean;
+   }
+
+   /* Setup gather (input) components */
+   g_sz_bytes = ((req->incnt + 3) / 4) * sizeof(struct sglist_component);
+   info->gather_components = kzalloc((g_sz_bytes), GFP_KERNEL);


unnecessary parenthesis


+   if (!info->gather_components) {
+   ret = -ENOMEM;
+   goto  scatter_gather_clean;
+   }
+
+   ret = setup_sgio_components(cptvf, req->in,
+   req->incnt,
+   info->gather_components);
+   if (ret) {
+   pr_err("Failed to setup gather list\n");
+   ret = -EFAULT;
+ 

Re: [PATCH 1/2] ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock

[Eric Ren]

On 01/06/2017 02:07 PM, Joseph Qi wrote:

Hi Eric,


On 17/1/5 23:31, Eric Ren wrote:

We are in the situation that we have to avoid recursive cluster locking,
but there is no way to check if a cluster lock has been taken by a
precess already.

Mostly, we can avoid recursive locking by writing code carefully.
However, we found that it's very hard to handle the routines that
are invoked directly by vfs code. For instance:

const struct inode_operations ocfs2_file_iops = {
 .permission = ocfs2_permission,
 .get_acl= ocfs2_iop_get_acl,
 .set_acl= ocfs2_iop_set_acl,
};

Both ocfs2_permission() and ocfs2_iop_get_acl() call ocfs2_inode_lock(PR):
do_sys_open
  may_open
   inode_permission
ocfs2_permission
 ocfs2_inode_lock() <=== first time
  generic_permission
   get_acl
ocfs2_iop_get_acl
ocfs2_inode_lock() <=== recursive one

A deadlock will occur if a remote EX request comes in between two
of ocfs2_inode_lock(). Briefly describe how the deadlock is formed:

On one hand, OCFS2_LOCK_BLOCKED flag of this lockres is set in
BAST(ocfs2_generic_handle_bast) when downconvert is started
on behalf of the remote EX lock request. Another hand, the recursive
cluster lock (the second one) will be blocked in in __ocfs2_cluster_lock()
because of OCFS2_LOCK_BLOCKED. But, the downconvert never complete, why?
because there is no chance for the first cluster lock on this node to be
unlocked - we block ourselves in the code path.

The idea to fix this issue is mostly taken from gfs2 code.
1. introduce a new field: struct ocfs2_lock_res.l_holders, to
keep track of the processes' pid  who has taken the cluster lock
of this lock resource;
2. introduce a new flag for ocfs2_inode_lock_full: OCFS2_META_LOCK_GETBH;
it means just getting back disk inode bh for us if we've got cluster lock.
3. export a helper: ocfs2_is_locked_by_me() is used to check if we
have got the cluster lock in the upper code path.

The tracking logic should be used by some of the ocfs2 vfs's callbacks,
to solve the recursive locking issue cuased by the fact that vfs routines
can call into each other.

The performance penalty of processing the holder list should only be seen
at a few cases where the tracking logic is used, such as get/set acl.

You may ask what if the first time we got a PR lock, and the second time
we want a EX lock? fortunately, this case never happens in the real world,
as far as I can see, including permission check, (get|set)_(acl|attr), and
the gfs2 code also do so.

Signed-off-by: Eric Ren 
---
  fs/ocfs2/dlmglue.c | 47 ---
  fs/ocfs2/dlmglue.h | 18 ++
  fs/ocfs2/ocfs2.h   |  1 +
  3 files changed, 63 insertions(+), 3 deletions(-)

diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
index 83d576f..500bda4 100644
--- a/fs/ocfs2/dlmglue.c
+++ b/fs/ocfs2/dlmglue.c
@@ -532,6 +532,7 @@ void ocfs2_lock_res_init_once(struct ocfs2_lock_res *res)
  init_waitqueue_head(>l_event);
  INIT_LIST_HEAD(>l_blocked_list);
  INIT_LIST_HEAD(>l_mask_waiters);
+INIT_LIST_HEAD(>l_holders);
  }
void ocfs2_inode_lock_res_init(struct ocfs2_lock_res *res,
@@ -749,6 +750,45 @@ void ocfs2_lock_res_free(struct ocfs2_lock_res *res)
  res->l_flags = 0UL;
  }
  +inline void ocfs2_add_holder(struct ocfs2_lock_res *lockres,
+   struct ocfs2_holder *oh)
+{
+INIT_LIST_HEAD(>oh_list);
+oh->oh_owner_pid =  get_pid(task_pid(current));
+
+spin_lock(>l_lock);
+list_add_tail(>oh_list, >l_holders);
+spin_unlock(>l_lock);
+}
+
+inline void ocfs2_remove_holder(struct ocfs2_lock_res *lockres,
+   struct ocfs2_holder *oh)
+{
+spin_lock(>l_lock);
+list_del(>oh_list);
+spin_unlock(>l_lock);
+
+put_pid(oh->oh_owner_pid);
+}
+
+inline struct ocfs2_holder *ocfs2_is_locked_by_me(struct ocfs2_lock_res 
*lockres)
+{
+struct ocfs2_holder *oh;
+struct pid *pid;
+
+/* look in the list of holders for one with the current task as owner */
+spin_lock(>l_lock);
+pid = task_pid(current);
+list_for_each_entry(oh, >l_holders, oh_list) {
+if (oh->oh_owner_pid == pid)
+goto out;
+}
+oh = NULL;
+out:
+spin_unlock(>l_lock);
+return oh;
+}

Since this ocfs2_holder won't be used in the caller, I suggest just return a 
bool value here.
Something like:
spin_lock();
list_for_each_entry() {
if (oh->oh_owner_pid == pid) {
spin_unlock();
return 1;
}
}
spin_unlock();
return 0;


Aha, you have the point. However, it is also reasonable to return the lock 
holder by the way.
When debugging with printk or crash, it's easy to get the pid of the holder 
without any further
analysis. So, I tend to keep it;-)

Thanks very much for your review!
Eric



Thanks,
Joseph

+
  static inline void ocfs2_inc_holders(struct ocfs2_lock_res *lockres,
   int level)
  {
@@ -2333,8 +2373,9 @@ int 

[PATCH] arm64: dts: exynos: Remove unsupported regulator-always-off property from TM2E

[Krzysztof Kozlowski]

The regulator property 'regulator-always-off' is not documented and not
supported.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
index 1db4e7f363a9..398f5e092b02 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
@@ -25,7 +25,6 @@
 
 _reg {
regulator-name = "UNUSED_LDO25";
-   regulator-always-off;
 };
 
 _reg {
-- 
2.9.3

[PATCH] arm64: dts: exynos: Remove unsupported regulator-always-off property from TM2E

[Krzysztof Kozlowski]

The regulator property 'regulator-always-off' is not documented and not
supported.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
index 1db4e7f363a9..398f5e092b02 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
@@ -25,7 +25,6 @@
 
 _reg {
regulator-name = "UNUSED_LDO25";
-   regulator-always-off;
 };
 
 _reg {
-- 
2.9.3

Re: [PATCH v2 01/2] rtl8192u: r8192U:- Do not use 'asm/io.h' directly, use 'linux/io.h'.

[Greg KH]

On Fri, Jan 06, 2017 at 11:46:11AM +0530, Arvind Yadav wrote:
> 'commit 2584cf83578c ("arch, drivers: don't
> include  directly, use  instead")'
> Make uniform definition of ioremap, ioremap_wc, ioremap_wt and
> ioremap_cache, tree-wide.

I still don't understand what this means at all, do you?

What does the "Make uniform..." sentance mean in relation to this simple
patch that just changes the include file used?

confused,

greg k-h

Re: [PATCH v2 01/2] rtl8192u: r8192U:- Do not use 'asm/io.h' directly, use 'linux/io.h'.

[Greg KH]

On Fri, Jan 06, 2017 at 11:46:11AM +0530, Arvind Yadav wrote:
> 'commit 2584cf83578c ("arch, drivers: don't
> include  directly, use  instead")'
> Make uniform definition of ioremap, ioremap_wc, ioremap_wt and
> ioremap_cache, tree-wide.

I still don't understand what this means at all, do you?

What does the "Make uniform..." sentance mean in relation to this simple
patch that just changes the include file used?

confused,

greg k-h

Re: [RFC 0/1] Platform driver support for 'amd5536udc' driver

[Raviteja Garimella]

Hi Arnd,

On Fri, Jan 6, 2017 at 3:33 AM, Arnd Bergmann  wrote:
> On Thursday, January 5, 2017 1:53:16 PM CET Raviteja Garimella wrote:
>> The UDC is based on Synopsys Designware core USB (2.0) Device controller
>> IP.
> ...
>> This is a request for comments from maintainers/others regarding approach
>> on whether to have 2 different drivers (one each for AMD and Broadcom)
>> with a common library (3 files in total), or have a single driver like
>> it's done in this patch and have the driver filename changed to some
>> common name based on ther underlying IP, like snps_udc.c.
>
> I have not looked at the code at all, so sorry for my ignorance, but
> isn't the IP block you describe the one that drivers/usb/dwc2/ is for?
> Could you add support for the Broadcom hardware there instead?

The current driver I submitted is for a different Synopsys IP (USB
Device Controller IP,
not the HS OTG). It's confirmed by John Youn (from Synopsys) earlier.

Thanks,
Ravi
>
> Arnd

Re: [RFC 0/1] Platform driver support for 'amd5536udc' driver

[Raviteja Garimella]

Hi Arnd,

On Fri, Jan 6, 2017 at 3:33 AM, Arnd Bergmann  wrote:
> On Thursday, January 5, 2017 1:53:16 PM CET Raviteja Garimella wrote:
>> The UDC is based on Synopsys Designware core USB (2.0) Device controller
>> IP.
> ...
>> This is a request for comments from maintainers/others regarding approach
>> on whether to have 2 different drivers (one each for AMD and Broadcom)
>> with a common library (3 files in total), or have a single driver like
>> it's done in this patch and have the driver filename changed to some
>> common name based on ther underlying IP, like snps_udc.c.
>
> I have not looked at the code at all, so sorry for my ignorance, but
> isn't the IP block you describe the one that drivers/usb/dwc2/ is for?
> Could you add support for the Broadcom hardware there instead?

The current driver I submitted is for a different Synopsys IP (USB
Device Controller IP,
not the HS OTG). It's confirmed by John Youn (from Synopsys) earlier.

Thanks,
Ravi
>
> Arnd

Re: [PATCH v2 3/4] ARM64: dts: exynos5433: use macros for pinctrl configuration on Exynos5433

[Krzysztof Kozlowski]

On Fri, Dec 30, 2016 at 01:14:20PM +0900, Andi Shyti wrote:
> Use the macros defined in include/dt-bindings/pinctrl/samsung.h
> instead of hardcoded values.
> 
> Signed-off-by: Andi Shyti 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 348 
> +++--
>  1 file changed, 175 insertions(+), 173 deletions(-)
> 

Thanks, applied.

Best regards,
Krzysztof

Re: [PATCH v2 4/4] ARM64: dts: TM2: comply to the samsung pinctrl naming convention

[Krzysztof Kozlowski]

On Fri, Dec 30, 2016 at 01:14:21PM +0900, Andi Shyti wrote:
> Change the PIN() macro definition so that it can use the macros
> from pinctrl/samsung.h header file.
> 
> Signed-off-by: Andi Shyti 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi |  25 +-
>  arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  | 254 
> ++---
>  2 files changed, 133 insertions(+), 146 deletions(-)
> 

Thanks, applied (here and in 3/4 with fixed subject).

Best regards,
Krzysztof

RE: [PATCH 1/3] dt-bindings: Update QorIQ TMU thermal bindings

[Y.T. Tang]

Seems like Troy's email client has issues which causes his reply is unreadable 
in patchwork.
Please ignore it in patchwork. 

Regards,
Yuantian

> -Original Message-
> From: Troy Jia
> Sent: Thursday, January 05, 2017 10:29 AM
> To: Scott Wood ; rui.zh...@intel.com;
> edubez...@gmail.com; Y.T. Tang ;
> robh...@kernel.org
> Cc: linux...@vger.kernel.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: RE: [PATCH 1/3] dt-bindings: Update QorIQ TMU thermal bindings
> 
> 
> 
> > -Original Message-
> > From: Scott Wood [mailto:o...@buserror.net]
> > Sent: Wednesday, January 04, 2017 6:38 PM
> > To: Troy Jia ; rui.zh...@intel.com;
> > edubez...@gmail.com; Y.T. Tang ;
> > robh...@kernel.org
> > Cc: linux...@vger.kernel.org; devicet...@vger.kernel.org; linux-
> > ker...@vger.kernel.org
> > Subject: Re: [PATCH 1/3] dt-bindings: Update QorIQ TMU thermal
> > bindings
> >
> > On Wed, 2017-01-04 at 16:57 +0800, Jia Hongtao wrote:
> > > For different types of SoC the sensor id and endianness may vary.
> > > "#thermal-sensor-cells" is used to provide sensor id information.
> > > "little-endian" property is to tell the endianness of TMU.
> > >
> > > Signed-off-by: Jia Hongtao 
> > > Acked-by: Rob Herring 
> > > ---
> > >  Documentation/devicetree/bindings/thermal/qoriq-thermal.txt | 7
> > > +++
> > >  1 file changed, 7 insertions(+)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
> > > b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
> > > index 66223d5..20ca4ef 100644
> > > --- a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
> > > +++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
> > > @@ -17,6 +17,12 @@ Required properties:
> > >   calibration data, as specified by the SoC reference manual.
> > >   The first cell of each pair is the value to be written to TTCFGR,
> > >   and the second is the value to be written to TSCFGR.
> > > +- #thermal-sensor-cells : Must be 1. The sensor specifier is the
> monitoring
> > > + site ID, and represents the "n" in TRITSRn and TRATSRn.
> >
> > I assume the driver will continue to work with existing device trees
> > where this information is absent?  If so, ACK for the whole series.
> 
> Yes. The driver works for all existing device trees.
> 
> Thanks for the ACK.
> 
> >
> > -Scott

Re: [PATCH v2 3/4] ARM64: dts: exynos5433: use macros for pinctrl configuration on Exynos5433

[Krzysztof Kozlowski]

On Fri, Dec 30, 2016 at 01:14:20PM +0900, Andi Shyti wrote:
> Use the macros defined in include/dt-bindings/pinctrl/samsung.h
> instead of hardcoded values.
> 
> Signed-off-by: Andi Shyti 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 348 
> +++--
>  1 file changed, 175 insertions(+), 173 deletions(-)
> 

Thanks, applied.

Best regards,
Krzysztof

Re: [PATCH v2 4/4] ARM64: dts: TM2: comply to the samsung pinctrl naming convention

[Krzysztof Kozlowski]

On Fri, Dec 30, 2016 at 01:14:21PM +0900, Andi Shyti wrote:
> Change the PIN() macro definition so that it can use the macros
> from pinctrl/samsung.h header file.
> 
> Signed-off-by: Andi Shyti 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi |  25 +-
>  arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  | 254 
> ++---
>  2 files changed, 133 insertions(+), 146 deletions(-)
> 

Thanks, applied (here and in 3/4 with fixed subject).

Best regards,
Krzysztof

RE: [PATCH 1/3] dt-bindings: Update QorIQ TMU thermal bindings

[Y.T. Tang]

Seems like Troy's email client has issues which causes his reply is unreadable 
in patchwork.
Please ignore it in patchwork. 

Regards,
Yuantian

> -Original Message-
> From: Troy Jia
> Sent: Thursday, January 05, 2017 10:29 AM
> To: Scott Wood ; rui.zh...@intel.com;
> edubez...@gmail.com; Y.T. Tang ;
> robh...@kernel.org
> Cc: linux...@vger.kernel.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: RE: [PATCH 1/3] dt-bindings: Update QorIQ TMU thermal bindings
> 
> 
> 
> > -Original Message-
> > From: Scott Wood [mailto:o...@buserror.net]
> > Sent: Wednesday, January 04, 2017 6:38 PM
> > To: Troy Jia ; rui.zh...@intel.com;
> > edubez...@gmail.com; Y.T. Tang ;
> > robh...@kernel.org
> > Cc: linux...@vger.kernel.org; devicet...@vger.kernel.org; linux-
> > ker...@vger.kernel.org
> > Subject: Re: [PATCH 1/3] dt-bindings: Update QorIQ TMU thermal
> > bindings
> >
> > On Wed, 2017-01-04 at 16:57 +0800, Jia Hongtao wrote:
> > > For different types of SoC the sensor id and endianness may vary.
> > > "#thermal-sensor-cells" is used to provide sensor id information.
> > > "little-endian" property is to tell the endianness of TMU.
> > >
> > > Signed-off-by: Jia Hongtao 
> > > Acked-by: Rob Herring 
> > > ---
> > >  Documentation/devicetree/bindings/thermal/qoriq-thermal.txt | 7
> > > +++
> > >  1 file changed, 7 insertions(+)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
> > > b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
> > > index 66223d5..20ca4ef 100644
> > > --- a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
> > > +++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
> > > @@ -17,6 +17,12 @@ Required properties:
> > >   calibration data, as specified by the SoC reference manual.
> > >   The first cell of each pair is the value to be written to TTCFGR,
> > >   and the second is the value to be written to TSCFGR.
> > > +- #thermal-sensor-cells : Must be 1. The sensor specifier is the
> monitoring
> > > + site ID, and represents the "n" in TRITSRn and TRATSRn.
> >
> > I assume the driver will continue to work with existing device trees
> > where this information is absent?  If so, ACK for the whole series.
> 
> Yes. The driver works for all existing device trees.
> 
> Thanks for the ACK.
> 
> >
> > -Scott

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

[Ingo Molnar]

* Thomas Garnier  wrote:

> >> Not sure I fully understood and I don't want to miss an important point. 
> >> Do 
> >> you mean making GDT (remapping and per-cpu) read-only and switch the 
> >> writeable flag only when we write to the per-cpu entry?
> >
> > What I mean is: write to the GDT through normal percpu access (or whatever 
> > the 
> > normal mapping is) but load a read-only alias into the GDT register.  As 
> > long 
> > as nothing ever tries to write through the GDTR alias, no page faults will 
> > be 
> > generated.  So we just need to make sure that nothing ever writes to it 
> > through GDTR.  AFAIK the only reason the CPU ever writes to the address in 
> > GDTR is to set an accessed bit.
> 
> A write is made when we use load_TR_desc (ltr). I didn't see any other yet.

Is this write to the GDT, generated by the LTR instruction, done 
unconditionally 
by the hardware?

Thanks,

Ingo

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

[Ingo Molnar]

* Thomas Garnier  wrote:

> >> Not sure I fully understood and I don't want to miss an important point. 
> >> Do 
> >> you mean making GDT (remapping and per-cpu) read-only and switch the 
> >> writeable flag only when we write to the per-cpu entry?
> >
> > What I mean is: write to the GDT through normal percpu access (or whatever 
> > the 
> > normal mapping is) but load a read-only alias into the GDT register.  As 
> > long 
> > as nothing ever tries to write through the GDTR alias, no page faults will 
> > be 
> > generated.  So we just need to make sure that nothing ever writes to it 
> > through GDTR.  AFAIK the only reason the CPU ever writes to the address in 
> > GDTR is to set an accessed bit.
> 
> A write is made when we use load_TR_desc (ltr). I didn't see any other yet.

Is this write to the GDT, generated by the LTR instruction, done 
unconditionally 
by the hardware?

Thanks,

Ingo

Re: [PATCH] iommu: Drop the of_iommu_{set/get}_ops() interface

[Yong Wu]

On Wed, 2017-01-04 at 15:11 +, Robin Murphy wrote:
> [+Yong Wu for mtk_iommu]
> 
> On 03/01/17 17:34, Lorenzo Pieralisi wrote:
> > With the introduction of the new iommu_{register/get}_instance()
> > interface in commit e4f10ffe4c9b ("iommu: Make of_iommu_set/get_ops() DT
> > agnostic") (based on struct fwnode_handle as look-up token, so firmware
> > agnostic) to register IOMMU instances with the core IOMMU layer there is
> > no reason to keep the old OF based interface around any longer.
> > 
> > Convert all the IOMMU drivers (and OF IOMMU core code) that rely on the
> > of_iommu_{set/get}_ops() to the new kernel interface to register/retrieve
> > IOMMU instances and remove the of_iommu_{set/get}_ops() remaining glue
> > code in order to complete the interface rework.
> 
> Reviewed-by: Robin Murphy 
> 
> Looking at before-and-after disassemblies, of_iommu.o is binary
> identical, and exynos-iommu.o differs only in the use of dev->fwnode
> rather than >of_node->fwnode (and is binary identical if I hack it
> back to the latter). I'm not sure why the (GCC 6.2) codegen for
> mtk_iommu.o changes quite so much when merely replacing a callsite with
> the contents of its static inline callee, but it does :/
> 
> Robin.
> 

For MTK IOMMU,

Tested-by: Yong Wu 

Thanks.

Re: [PATCH] iommu: Drop the of_iommu_{set/get}_ops() interface

[Yong Wu]

On Wed, 2017-01-04 at 15:11 +, Robin Murphy wrote:
> [+Yong Wu for mtk_iommu]
> 
> On 03/01/17 17:34, Lorenzo Pieralisi wrote:
> > With the introduction of the new iommu_{register/get}_instance()
> > interface in commit e4f10ffe4c9b ("iommu: Make of_iommu_set/get_ops() DT
> > agnostic") (based on struct fwnode_handle as look-up token, so firmware
> > agnostic) to register IOMMU instances with the core IOMMU layer there is
> > no reason to keep the old OF based interface around any longer.
> > 
> > Convert all the IOMMU drivers (and OF IOMMU core code) that rely on the
> > of_iommu_{set/get}_ops() to the new kernel interface to register/retrieve
> > IOMMU instances and remove the of_iommu_{set/get}_ops() remaining glue
> > code in order to complete the interface rework.
> 
> Reviewed-by: Robin Murphy 
> 
> Looking at before-and-after disassemblies, of_iommu.o is binary
> identical, and exynos-iommu.o differs only in the use of dev->fwnode
> rather than >of_node->fwnode (and is binary identical if I hack it
> back to the latter). I'm not sure why the (GCC 6.2) codegen for
> mtk_iommu.o changes quite so much when merely replacing a callsite with
> the contents of its static inline callee, but it does :/
> 
> Robin.
> 

For MTK IOMMU,

Tested-by: Yong Wu 

Thanks.

Re: [PATCH v2 2/4] pinctrl: dt-bindings: samsung: add drive strength macros for Exynos5433

[Krzysztof Kozlowski]

On Fri, Dec 30, 2016 at 02:30:47PM +0100, Linus Walleij wrote:
> On Fri, Dec 30, 2016 at 5:14 AM, Andi Shyti  wrote:
> 
> > Commit 5db7e3bb87df ("pinctrl: dt-bindings: samsung: Add header with
> > values used for configuration") has added a header file for defining the
> > pinctrl values in order to avoid hardcoded settings in the Exynos
> > DTS related files.
> >
> > Extend samsung.h to the Exynos5433 for drive strength values
> > which are strictly related to the particular SoC and may defer
> > from others.
> >
> > Signed-off-by: Andi Shyti 
> 
> Patch applied with Chanwoo's review tag.

As agreed, applied with your ack to samsung-soc. I put it on separate
branch so I can provide a tag if needed.

Best regards,
Krzysztof

Re: [PATCH v2 2/4] pinctrl: dt-bindings: samsung: add drive strength macros for Exynos5433

[Krzysztof Kozlowski]

On Fri, Dec 30, 2016 at 02:30:47PM +0100, Linus Walleij wrote:
> On Fri, Dec 30, 2016 at 5:14 AM, Andi Shyti  wrote:
> 
> > Commit 5db7e3bb87df ("pinctrl: dt-bindings: samsung: Add header with
> > values used for configuration") has added a header file for defining the
> > pinctrl values in order to avoid hardcoded settings in the Exynos
> > DTS related files.
> >
> > Extend samsung.h to the Exynos5433 for drive strength values
> > which are strictly related to the particular SoC and may defer
> > from others.
> >
> > Signed-off-by: Andi Shyti 
> 
> Patch applied with Chanwoo's review tag.

As agreed, applied with your ack to samsung-soc. I put it on separate
branch so I can provide a tag if needed.

Best regards,
Krzysztof

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

[Ingo Molnar]

* Arjan van de Ven  wrote:

> On 1/5/2017 9:54 AM, Thomas Garnier wrote:
> 
> > That's my goal too. I started by doing a RO remap and got couple problems 
> > with 
> > hibernation. I can try again for the next iteration or delay it for another 
> > patch. I also need to look at KVM GDT usage, I am not familiar with it yet.
> 
> don't we write to the GDT as part of the TLS segment stuff for glibc ?

Yes - but the idea would be to have two virtual memory aliases:

 1) A world-readable RO mapping of the GDT put into the fixmap area 
(randomization
is not really required as the SGDT instruction exposes it anyway).

This read-only GDT mapping has two advantages:

 - Because the GDT address is read-only it cannot be used by exploits as an 
   easy trampoline for 100% safe, deterministic rooting of the system from 
a 
   local process.

 - Even on older CPUs the SGDT instruction won't expose the absolute 
address 
   of critical kernel data structures.

 2) A kernel-only RW mapping in the linear kernel memory map where the original
page is - randomized (as a natural part of kernel physical and virtual 
memory
randomization) and only known and accessible to the kernel, SGDT doesn't 
expose it even on older CPUs.

This way we IMHO have the best of both worlds.

Assuming there are no strange CPU errata surfacing if we use a RO GDT - OTOH 
that 
should be fairly easy to test for, and worst-case we could quirk-off the 
feature 
on CPUs where this cannot be done safely.

Thanks,

Ingo

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

[Ingo Molnar]

* Arjan van de Ven  wrote:

> On 1/5/2017 9:54 AM, Thomas Garnier wrote:
> 
> > That's my goal too. I started by doing a RO remap and got couple problems 
> > with 
> > hibernation. I can try again for the next iteration or delay it for another 
> > patch. I also need to look at KVM GDT usage, I am not familiar with it yet.
> 
> don't we write to the GDT as part of the TLS segment stuff for glibc ?

Yes - but the idea would be to have two virtual memory aliases:

 1) A world-readable RO mapping of the GDT put into the fixmap area 
(randomization
is not really required as the SGDT instruction exposes it anyway).

This read-only GDT mapping has two advantages:

 - Because the GDT address is read-only it cannot be used by exploits as an 
   easy trampoline for 100% safe, deterministic rooting of the system from 
a 
   local process.

 - Even on older CPUs the SGDT instruction won't expose the absolute 
address 
   of critical kernel data structures.

 2) A kernel-only RW mapping in the linear kernel memory map where the original
page is - randomized (as a natural part of kernel physical and virtual 
memory
randomization) and only known and accessible to the kernel, SGDT doesn't 
expose it even on older CPUs.

This way we IMHO have the best of both worlds.

Assuming there are no strange CPU errata surfacing if we use a RO GDT - OTOH 
that 
should be fairly easy to test for, and worst-case we could quirk-off the 
feature 
on CPUs where this cannot be done safely.

Thanks,

Ingo

Re: [PATCHv3 2/5] arm: mvebu: support for SMP on 98DX3336 SoC

[Stephen Boyd]

On 01/06, Chris Packham wrote:
> diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
> index 46c742d3bd41..3c9ab9a008ad 100644
> --- a/arch/arm/mach-mvebu/platsmp.c
> +++ b/arch/arm/mach-mvebu/platsmp.c
> @@ -182,5 +182,48 @@ const struct smp_operations armada_xp_smp_ops 
> __initconst = {
>  #endif
>  };
>  
> +static int mv98dx3236_boot_secondary(unsigned int cpu, struct task_struct 
> *idle)
> +{
> + int ret, hw_cpu;
> +
> + pr_info("Booting CPU %d\n", cpu);

Doesn't the core already print something when bringing up CPUs?
This message seems redundant.

> +
> + hw_cpu = cpu_logical_map(cpu);
> + set_secondary_cpu_clock(hw_cpu);
> + mv98dx3236_resume_set_cpu_boot_addr(hw_cpu,
> + armada_xp_secondary_startup);
> +
> + /*
> +  * This is needed to wake up CPUs in the offline state after
> +  * using CPU hotplug.
> +  */
> + arch_send_wakeup_ipi_mask(cpumask_of(cpu));
> +
> + /*
> +  * This is needed to take secondary CPUs out of reset on the
> +  * initial boot.
> +  */
> + ret = mvebu_cpu_reset_deassert(hw_cpu);
> + if (ret) {
> + pr_warn("unable to boot CPU: %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +struct smp_operations mv98dx3236_smp_ops __initdata = {

static const __initconst?

> + .smp_init_cpus  = armada_xp_smp_init_cpus,
> + .smp_prepare_cpus   = armada_xp_smp_prepare_cpus,
> + .smp_boot_secondary = mv98dx3236_boot_secondary,
> + .smp_secondary_init = armada_xp_secondary_init,
> +#ifdef CONFIG_HOTPLUG_CPU
> + .cpu_die= armada_xp_cpu_die,
> + .cpu_kill   = armada_xp_cpu_kill,
> +#endif
> +};
> +
>  CPU_METHOD_OF_DECLARE(armada_xp_smp, "marvell,armada-xp-smp",
> _xp_smp_ops);
> +CPU_METHOD_OF_DECLARE(mv98dx3236_smp, "marvell,98dx3236-smp",
> +   _smp_ops);
> diff --git a/arch/arm/mach-mvebu/pmsu-98dx3236.c 
> b/arch/arm/mach-mvebu/pmsu-98dx3236.c
> new file mode 100644
> index ..1052674dd439
> --- /dev/null
> +++ b/arch/arm/mach-mvebu/pmsu-98dx3236.c
> @@ -0,0 +1,52 @@
> +/**
> + * CPU resume support for 98DX3236 internal CPU (a.k.a. MSYS).
> + */
> +
> +#define pr_fmt(fmt) "mv98dx3236-resume: " fmt
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "common.h"
> +
> +static void __iomem *mv98dx3236_resume_base;
> +#define MV98DX3236_CPU_RESUME_CTRL_OFFSET0x08
> +#define MV98DX3236_CPU_RESUME_ADDR_OFFSET0x04
> +
> +static const struct of_device_id of_mv98dx3236_resume_table[] = {
> + {.compatible = "marvell,98dx3336-resume-ctrl",},
> + { /* end of list */ },
> +};
> +
> +void mv98dx3236_resume_set_cpu_boot_addr(int hw_cpu, void *boot_addr)
> +{
> + WARN_ON(hw_cpu != 1);
> +
> + writel(0, mv98dx3236_resume_base + MV98DX3236_CPU_RESUME_CTRL_OFFSET);
> + writel(virt_to_phys(boot_addr), mv98dx3236_resume_base +
> +MV98DX3236_CPU_RESUME_ADDR_OFFSET);
> +}
> +
> +static int __init mv98dx3236_resume_init(void)
> +{
> + struct device_node *np;
> + void __iomem *base;
> +
> + np = of_find_matching_node(NULL, of_mv98dx3236_resume_table);
> + if (!np)
> + return 0;

Is there any reason we can't just look for this node from the
smp_ops and map it if it isn't mapped yet? Seems simpler than a
whole new file and initcall.

> +
> + base = of_io_request_and_map(np, 0, of_node_full_name(np));
> + if (IS_ERR(base)) {
> + pr_err("unable to map registers\n");

Doesn't of_io_request_and_map() spit out an error on failure
already?

> + of_node_put(np);

This could be done before the if statement and then the duplicate
statement deleted.

> + return PTR_ERR(mv98dx3236_resume_base);

Should be PTR_ERR(base)?

> + }
> +
> + mv98dx3236_resume_base = base;
> + of_node_put(np);
> + return 0;
> +}

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCHv3 2/5] arm: mvebu: support for SMP on 98DX3336 SoC

[Stephen Boyd]

On 01/06, Chris Packham wrote:
> diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
> index 46c742d3bd41..3c9ab9a008ad 100644
> --- a/arch/arm/mach-mvebu/platsmp.c
> +++ b/arch/arm/mach-mvebu/platsmp.c
> @@ -182,5 +182,48 @@ const struct smp_operations armada_xp_smp_ops 
> __initconst = {
>  #endif
>  };
>  
> +static int mv98dx3236_boot_secondary(unsigned int cpu, struct task_struct 
> *idle)
> +{
> + int ret, hw_cpu;
> +
> + pr_info("Booting CPU %d\n", cpu);

Doesn't the core already print something when bringing up CPUs?
This message seems redundant.

> +
> + hw_cpu = cpu_logical_map(cpu);
> + set_secondary_cpu_clock(hw_cpu);
> + mv98dx3236_resume_set_cpu_boot_addr(hw_cpu,
> + armada_xp_secondary_startup);
> +
> + /*
> +  * This is needed to wake up CPUs in the offline state after
> +  * using CPU hotplug.
> +  */
> + arch_send_wakeup_ipi_mask(cpumask_of(cpu));
> +
> + /*
> +  * This is needed to take secondary CPUs out of reset on the
> +  * initial boot.
> +  */
> + ret = mvebu_cpu_reset_deassert(hw_cpu);
> + if (ret) {
> + pr_warn("unable to boot CPU: %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +struct smp_operations mv98dx3236_smp_ops __initdata = {

static const __initconst?

> + .smp_init_cpus  = armada_xp_smp_init_cpus,
> + .smp_prepare_cpus   = armada_xp_smp_prepare_cpus,
> + .smp_boot_secondary = mv98dx3236_boot_secondary,
> + .smp_secondary_init = armada_xp_secondary_init,
> +#ifdef CONFIG_HOTPLUG_CPU
> + .cpu_die= armada_xp_cpu_die,
> + .cpu_kill   = armada_xp_cpu_kill,
> +#endif
> +};
> +
>  CPU_METHOD_OF_DECLARE(armada_xp_smp, "marvell,armada-xp-smp",
> _xp_smp_ops);
> +CPU_METHOD_OF_DECLARE(mv98dx3236_smp, "marvell,98dx3236-smp",
> +   _smp_ops);
> diff --git a/arch/arm/mach-mvebu/pmsu-98dx3236.c 
> b/arch/arm/mach-mvebu/pmsu-98dx3236.c
> new file mode 100644
> index ..1052674dd439
> --- /dev/null
> +++ b/arch/arm/mach-mvebu/pmsu-98dx3236.c
> @@ -0,0 +1,52 @@
> +/**
> + * CPU resume support for 98DX3236 internal CPU (a.k.a. MSYS).
> + */
> +
> +#define pr_fmt(fmt) "mv98dx3236-resume: " fmt
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "common.h"
> +
> +static void __iomem *mv98dx3236_resume_base;
> +#define MV98DX3236_CPU_RESUME_CTRL_OFFSET0x08
> +#define MV98DX3236_CPU_RESUME_ADDR_OFFSET0x04
> +
> +static const struct of_device_id of_mv98dx3236_resume_table[] = {
> + {.compatible = "marvell,98dx3336-resume-ctrl",},
> + { /* end of list */ },
> +};
> +
> +void mv98dx3236_resume_set_cpu_boot_addr(int hw_cpu, void *boot_addr)
> +{
> + WARN_ON(hw_cpu != 1);
> +
> + writel(0, mv98dx3236_resume_base + MV98DX3236_CPU_RESUME_CTRL_OFFSET);
> + writel(virt_to_phys(boot_addr), mv98dx3236_resume_base +
> +MV98DX3236_CPU_RESUME_ADDR_OFFSET);
> +}
> +
> +static int __init mv98dx3236_resume_init(void)
> +{
> + struct device_node *np;
> + void __iomem *base;
> +
> + np = of_find_matching_node(NULL, of_mv98dx3236_resume_table);
> + if (!np)
> + return 0;

Is there any reason we can't just look for this node from the
smp_ops and map it if it isn't mapped yet? Seems simpler than a
whole new file and initcall.

> +
> + base = of_io_request_and_map(np, 0, of_node_full_name(np));
> + if (IS_ERR(base)) {
> + pr_err("unable to map registers\n");

Doesn't of_io_request_and_map() spit out an error on failure
already?

> + of_node_put(np);

This could be done before the if statement and then the duplicate
statement deleted.

> + return PTR_ERR(mv98dx3236_resume_base);

Should be PTR_ERR(base)?

> + }
> +
> + mv98dx3236_resume_base = base;
> + of_node_put(np);
> + return 0;
> +}

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

[Ingo Molnar]

* Thomas Garnier  wrote:

> > Thanks,
> >
> > Ingo
> 
> Ingo: I saw the 5-level page table support being sent through. Do you
> want me to wait for it to be -next? (Given it will need to be changed
> too).

Please just base your bits on Linus's latest tree - we'll sort out any
conflicts as/when they happen.

Thanks,

Ingo

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

[Ingo Molnar]

* Thomas Garnier  wrote:

> > Thanks,
> >
> > Ingo
> 
> Ingo: I saw the 5-level page table support being sent through. Do you
> want me to wait for it to be -next? (Given it will need to be changed
> too).

Please just base your bits on Linus's latest tree - we'll sort out any
conflicts as/when they happen.

Thanks,

Ingo

Re: [PATCH v2 perf/core] perf script: fix a use after free crash.

[Krister Johansen]

On Wed, Jan 04, 2017 at 12:37:39AM -0800, Krister Johansen wrote:
> On Mon, Jan 02, 2017 at 09:30:33PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Jan 02, 2017 at 04:39:04PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Mon, Jan 02, 2017 at 02:36:57PM -0300, Arnaldo Carvalho de Melo 
> > > escreveu:
> > > > Em Mon, Jan 02, 2017 at 02:35:30PM -0300, Arnaldo Carvalho de Melo 
> > > > escreveu:
> > > > > Em Mon, Jan 02, 2017 at 12:15:14PM -0300, Arnaldo Carvalho de Melo 
> > > > > escreveu:
> > > >  {
> > > > zfree(>priv);
> > > > iter->he = NULL;
> > > > +   map__zput(al->map);
> > > 
> > > What this pairs to? I was expecting that since this is called via:
> > > 
> > >hist_entry_iter__add()
> > >{
> > >
> > >err2 = iter->ops->finish_entry(iter, al);
> > >}
> > > 
> > > Then it would have to match something done earlier in
> > > hist_entry_iter__add(), most likely by some iter->ops->() method, but I
> > > couldn'd find anything to that extent, can you clarify?
> > 
> > With the following patch it has been running all day, care to explain
> > why it is needed? I need to run this on valgrind or with Masami's
> > refcount debugger to get more clues :-\
>
> Let me try a version of this patch that dispenses with the code in both
> fill_callchain_info() and iter_finish_cumulative_entry.  However, before
> I do that I'll make sure I can figure out how to reproduce the core that
> you were seeing.  I don't want to send you yet another patch that
> doesn't run.  The busy system may be the clue I needed.  I had been
> running these on a mostly idle system.

I was able to reproduce your assertion failure using more load on a
system.  After fixing up the issues caused by incorrectly updating the
refcounts in the hist_entry_iter's function pointers, I re-ran my own
tests and found that I was still getting a failure for 'perf report'.

The problem there seemed to be that a map was getting into a hist entry,
but was freed before the entry was actually created.  The call to
hist_entry__init() that took a reference on the map was actually getting
freed memory by the time it tried to increment the reference count.

To address that, I modified hist_entry_iter__add() to take a reference
on the incoming al->map, if one exists.  It drops that reference on the
way out of the function.  With that change, I'm able to pass both your
'perf top' test under load and my own tests against a kernel without
debug info, but a kmod that has it.

I'll send out a v3 in just a moment.

Thanks again,

-K

Re: [PATCH] MAINTAINERS: Add EXYNOS5433 ARM architectures entry as a supporter

[Krzysztof Kozlowski]

On Fri, Jan 06, 2017 at 12:21:44PM +0900, Chanwoo Choi wrote:
> On 2017년 01월 06일 01:59, Krzysztof Kozlowski wrote:
> > On Thu, Jan 05, 2017 at 10:41:04PM +0900, Andi Shyti wrote:
> >> Hi Daniel,
> >>
>  +ARM/SAMSUNG EXYNOS5433 ARM ARCHITECTURES
>  +M:  Chanwoo Choi 
>  +R:  Andi Shyti 
>  +L:  linux-samsung-...@vger.kernel.org (moderated for 
>  non-subscribers)
>  +S:  Supported
>  +F:  arch/arm64/boot/dts/exynos/exynos5433*
>  +
> >>>
> >>> Does it make sense to add a MAINTAINER entry for some dts files ?
> >>
> >> I think it does considering that exynos5433* files are more then
> >> the half of the arm64/.../exynos/ directory.
> >>
> >> Besides Chanwoo has authored all of them (almost) and doesn't
> >> appear from the get_maintainers script.
> > 
> > He appears:
> > 1. Kukjin Kim  (maintainer:ARM/SAMSUNG EXYNOS ARM 
> > ARCHITECTURES)
> > 
> > 2. Krzysztof Kozlowski  (maintainer:ARM/SAMSUNG EXYNOS ARM 
> > ARCHITECTURES,commit_signer:26/24=100%,authored:4/24=17%)
> > 
> > 3. Javier Martinez Canillas  (reviewer:ARM/SAMSUNG 
> > EXYNOS ARM ARCHITECTURES,commit_signer:6/24=25%)
> > 
> > 4. Marek Szyprowski  
> > (commit_signer:12/24=50%,authored:8/24=33%)
> > 
> > 5. Chanwoo Choi  
> > (commit_signer:9/24=38%,authored:3/24=12%)
> > 
> > 6. Sylwester Nawrocki  (commit_signer:9/24=38%)
> > 
> > (sorry if lines are wrapped)
> 
> I have a question.
> 
> When I tested the get_maintainer script with Exynos5444 patch,
> I cannot get the same result from you.

The behavior of get_maintainers.pl changed few months ago and now it
prints recent GIT activity only when there are no maintainers. To me
personally, this is desired because otherwise a lot of people will be
spammed on every patch. If someone wants to notify not only maintainers
but also other people then he should use --git (which was used for
output above).

Best regards,
Krzysztof

> 
> I tested the following patch[1] which was already merged by Marek.
> [1] commit-id: 74c78036d5b5970266fa2075a17c9b89cabf873e
> - ("arm64: dts: exynos: TM2 - add support for MFC video codec device"
> 
> ./scripts/get_maintainer.pl 
> 0001-arm64-dts-exynos-TM2-add-support-for-MFC-video-codec.patch 
> Rob Herring  (maintainer:OPEN FIRMWARE AND FLATTENED 
> DEVICE TREE BINDINGS)
> Mark Rutland  (maintainer:OPEN FIRMWARE AND FLATTENED 
> DEVICE TREE BINDINGS)
> Catalin Marinas  (maintainer:ARM64 PORT (AARCH64 
> ARCHITECTURE))
> Will Deacon  (maintainer:ARM64 PORT (AARCH64 
> ARCHITECTURE))
> Kukjin Kim  (maintainer:ARM/SAMSUNG EXYNOS ARM 
> ARCHITECTURES)
> Krzysztof Kozlowski  (maintainer:ARM/SAMSUNG EXYNOS ARM 
> ARCHITECTURES)
> Javier Martinez Canillas  (reviewer:ARM/SAMSUNG 
> EXYNOS ARM ARCHITECTURES)
> devicet...@vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE 
> BINDINGS)
> linux-arm-ker...@lists.infradead.org (moderated list:ARM64 PORT (AARCH64 
> ARCHITECTURE))
> linux-samsung-...@vger.kernel.org (moderated list:ARM/SAMSUNG EXYNOS ARM 
> ARCHITECTURES)
> linux-kernel@vger.kernel.org (open list)
> 
> Also, when I tested the exynos5433-tm2e.dts patch, I got the same result.
> 
> > 
> > Best regards,
> > Krzysztof
> > 
> > 
> > 
> 
> 
> -- 
> Best Regards,
> Chanwoo Choi
> Samsung Electronics

> null

Re: [PATCH] MAINTAINERS: Add EXYNOS5433 ARM architectures entry as a supporter

[Krzysztof Kozlowski]

On Fri, Jan 06, 2017 at 12:21:44PM +0900, Chanwoo Choi wrote:
> On 2017년 01월 06일 01:59, Krzysztof Kozlowski wrote:
> > On Thu, Jan 05, 2017 at 10:41:04PM +0900, Andi Shyti wrote:
> >> Hi Daniel,
> >>
>  +ARM/SAMSUNG EXYNOS5433 ARM ARCHITECTURES
>  +M:  Chanwoo Choi 
>  +R:  Andi Shyti 
>  +L:  linux-samsung-...@vger.kernel.org (moderated for 
>  non-subscribers)
>  +S:  Supported
>  +F:  arch/arm64/boot/dts/exynos/exynos5433*
>  +
> >>>
> >>> Does it make sense to add a MAINTAINER entry for some dts files ?
> >>
> >> I think it does considering that exynos5433* files are more then
> >> the half of the arm64/.../exynos/ directory.
> >>
> >> Besides Chanwoo has authored all of them (almost) and doesn't
> >> appear from the get_maintainers script.
> > 
> > He appears:
> > 1. Kukjin Kim  (maintainer:ARM/SAMSUNG EXYNOS ARM 
> > ARCHITECTURES)
> > 
> > 2. Krzysztof Kozlowski  (maintainer:ARM/SAMSUNG EXYNOS ARM 
> > ARCHITECTURES,commit_signer:26/24=100%,authored:4/24=17%)
> > 
> > 3. Javier Martinez Canillas  (reviewer:ARM/SAMSUNG 
> > EXYNOS ARM ARCHITECTURES,commit_signer:6/24=25%)
> > 
> > 4. Marek Szyprowski  
> > (commit_signer:12/24=50%,authored:8/24=33%)
> > 
> > 5. Chanwoo Choi  
> > (commit_signer:9/24=38%,authored:3/24=12%)
> > 
> > 6. Sylwester Nawrocki  (commit_signer:9/24=38%)
> > 
> > (sorry if lines are wrapped)
> 
> I have a question.
> 
> When I tested the get_maintainer script with Exynos5444 patch,
> I cannot get the same result from you.

The behavior of get_maintainers.pl changed few months ago and now it
prints recent GIT activity only when there are no maintainers. To me
personally, this is desired because otherwise a lot of people will be
spammed on every patch. If someone wants to notify not only maintainers
but also other people then he should use --git (which was used for
output above).

Best regards,
Krzysztof

> 
> I tested the following patch[1] which was already merged by Marek.
> [1] commit-id: 74c78036d5b5970266fa2075a17c9b89cabf873e
> - ("arm64: dts: exynos: TM2 - add support for MFC video codec device"
> 
> ./scripts/get_maintainer.pl 
> 0001-arm64-dts-exynos-TM2-add-support-for-MFC-video-codec.patch 
> Rob Herring  (maintainer:OPEN FIRMWARE AND FLATTENED 
> DEVICE TREE BINDINGS)
> Mark Rutland  (maintainer:OPEN FIRMWARE AND FLATTENED 
> DEVICE TREE BINDINGS)
> Catalin Marinas  (maintainer:ARM64 PORT (AARCH64 
> ARCHITECTURE))
> Will Deacon  (maintainer:ARM64 PORT (AARCH64 
> ARCHITECTURE))
> Kukjin Kim  (maintainer:ARM/SAMSUNG EXYNOS ARM 
> ARCHITECTURES)
> Krzysztof Kozlowski  (maintainer:ARM/SAMSUNG EXYNOS ARM 
> ARCHITECTURES)
> Javier Martinez Canillas  (reviewer:ARM/SAMSUNG 
> EXYNOS ARM ARCHITECTURES)
> devicet...@vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE 
> BINDINGS)
> linux-arm-ker...@lists.infradead.org (moderated list:ARM64 PORT (AARCH64 
> ARCHITECTURE))
> linux-samsung-...@vger.kernel.org (moderated list:ARM/SAMSUNG EXYNOS ARM 
> ARCHITECTURES)
> linux-kernel@vger.kernel.org (open list)
> 
> Also, when I tested the exynos5433-tm2e.dts patch, I got the same result.
> 
> > 
> > Best regards,
> > Krzysztof
> > 
> > 
> > 
> 
> 
> -- 
> Best Regards,
> Chanwoo Choi
> Samsung Electronics

> null

Re: [PATCH v2 perf/core] perf script: fix a use after free crash.

[Krister Johansen]

On Wed, Jan 04, 2017 at 12:37:39AM -0800, Krister Johansen wrote:
> On Mon, Jan 02, 2017 at 09:30:33PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Jan 02, 2017 at 04:39:04PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Mon, Jan 02, 2017 at 02:36:57PM -0300, Arnaldo Carvalho de Melo 
> > > escreveu:
> > > > Em Mon, Jan 02, 2017 at 02:35:30PM -0300, Arnaldo Carvalho de Melo 
> > > > escreveu:
> > > > > Em Mon, Jan 02, 2017 at 12:15:14PM -0300, Arnaldo Carvalho de Melo 
> > > > > escreveu:
> > > >  {
> > > > zfree(>priv);
> > > > iter->he = NULL;
> > > > +   map__zput(al->map);
> > > 
> > > What this pairs to? I was expecting that since this is called via:
> > > 
> > >hist_entry_iter__add()
> > >{
> > >
> > >err2 = iter->ops->finish_entry(iter, al);
> > >}
> > > 
> > > Then it would have to match something done earlier in
> > > hist_entry_iter__add(), most likely by some iter->ops->() method, but I
> > > couldn'd find anything to that extent, can you clarify?
> > 
> > With the following patch it has been running all day, care to explain
> > why it is needed? I need to run this on valgrind or with Masami's
> > refcount debugger to get more clues :-\
>
> Let me try a version of this patch that dispenses with the code in both
> fill_callchain_info() and iter_finish_cumulative_entry.  However, before
> I do that I'll make sure I can figure out how to reproduce the core that
> you were seeing.  I don't want to send you yet another patch that
> doesn't run.  The busy system may be the clue I needed.  I had been
> running these on a mostly idle system.

I was able to reproduce your assertion failure using more load on a
system.  After fixing up the issues caused by incorrectly updating the
refcounts in the hist_entry_iter's function pointers, I re-ran my own
tests and found that I was still getting a failure for 'perf report'.

The problem there seemed to be that a map was getting into a hist entry,
but was freed before the entry was actually created.  The call to
hist_entry__init() that took a reference on the map was actually getting
freed memory by the time it tried to increment the reference count.

To address that, I modified hist_entry_iter__add() to take a reference
on the incoming al->map, if one exists.  It drops that reference on the
way out of the function.  With that change, I'm able to pass both your
'perf top' test under load and my own tests against a kernel without
debug info, but a kmod that has it.

I'll send out a v3 in just a moment.

Thanks again,

-K

[PATCH v3 perf/core] perf script: fix a use after free crash.

[Krister Johansen]

If dso__load_kcore frees all of the existing maps, but one has already
been attached to a callchain cursor node, then we can get a SIGSEGV in
any function that happens to try to use this invalid cursor.  Use the
existing map refcount mechanism to forestall cleanup of a map until the
cursor iterates past the node.

Signed-off-by: Krister Johansen 
---
 tools/perf/util/callchain.c | 11 +--
 tools/perf/util/callchain.h |  6 ++
 tools/perf/util/hist.c  | 10 ++
 3 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index 4292251..8b610dd 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -437,7 +437,7 @@ fill_node(struct callchain_node *node, struct 
callchain_cursor *cursor)
}
call->ip = cursor_node->ip;
call->ms.sym = cursor_node->sym;
-   call->ms.map = cursor_node->map;
+   call->ms.map = map__get(cursor_node->map);
 
if (cursor_node->branch) {
call->branch_count = 1;
@@ -477,6 +477,7 @@ add_child(struct callchain_node *parent,
 
list_for_each_entry_safe(call, tmp, >val, list) {
list_del(>list);
+   map__zput(call->ms.map);
free(call);
}
free(new);
@@ -761,6 +762,7 @@ merge_chain_branch(struct callchain_cursor *cursor,
list->ms.map, list->ms.sym,
false, NULL, 0, 0);
list_del(>list);
+   map__zput(list->ms.map);
free(list);
}
 
@@ -811,7 +813,8 @@ int callchain_cursor_append(struct callchain_cursor *cursor,
}
 
node->ip = ip;
-   node->map = map;
+   map__zput(node->map);
+   node->map = map__get(map);
node->sym = sym;
node->branch = branch;
node->nr_loop_iter = nr_loop_iter;
@@ -1142,11 +1145,13 @@ static void free_callchain_node(struct callchain_node 
*node)
 
list_for_each_entry_safe(list, tmp, >parent_val, list) {
list_del(>list);
+   map__zput(list->ms.map);
free(list);
}
 
list_for_each_entry_safe(list, tmp, >val, list) {
list_del(>list);
+   map__zput(list->ms.map);
free(list);
}
 
@@ -1210,6 +1215,7 @@ int callchain_node__make_parent_list(struct 
callchain_node *node)
goto out;
*new = *chain;
new->has_children = false;
+   map__get(new->ms.map);
list_add_tail(>list, );
}
parent = parent->parent;
@@ -1230,6 +1236,7 @@ int callchain_node__make_parent_list(struct 
callchain_node *node)
 out:
list_for_each_entry_safe(chain, new, , list) {
list_del(>list);
+   map__zput(chain->ms.map);
free(chain);
}
return -ENOMEM;
diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
index 35c8e37..4f4b60f 100644
--- a/tools/perf/util/callchain.h
+++ b/tools/perf/util/callchain.h
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include "event.h"
+#include "map.h"
 #include "symbol.h"
 
 #define HELP_PAD "\t\t\t\t"
@@ -184,8 +185,13 @@ int callchain_merge(struct callchain_cursor *cursor,
  */
 static inline void callchain_cursor_reset(struct callchain_cursor *cursor)
 {
+   struct callchain_cursor_node *node;
+
cursor->nr = 0;
cursor->last = >first;
+
+   for (node = cursor->first; node != NULL; node = node->next)
+   map__zput(node->map);
 }
 
 int callchain_cursor_append(struct callchain_cursor *cursor, u64 ip,
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 6770a96..9dabbae 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -1,6 +1,7 @@
 #include "util.h"
 #include "build-id.h"
 #include "hist.h"
+#include "map.h"
 #include "session.h"
 #include "sort.h"
 #include "evlist.h"
@@ -1019,6 +1020,12 @@ int hist_entry_iter__add(struct hist_entry_iter *iter, 
struct addr_location *al,
 int max_stack_depth, void *arg)
 {
int err, err2;
+   struct map *alm;
+
+   alm = NULL;
+
+   if (al && al->map)
+   alm = map__get(al->map);
 
err = sample__resolve_callchain(iter->sample, _cursor, 
>parent,
iter->evsel, al, max_stack_depth);
@@ -1058,6 +1065,9 @@ int hist_entry_iter__add(struct hist_entry_iter *iter, 
struct addr_location *al,
if (!err)
err = err2;
 
+   if (alm)
+   map__put(alm);
+
return err;
 }
 
-- 
2.7.4

[PATCH v3 perf/core] perf script: fix a use after free crash.

[Krister Johansen]

If dso__load_kcore frees all of the existing maps, but one has already
been attached to a callchain cursor node, then we can get a SIGSEGV in
any function that happens to try to use this invalid cursor.  Use the
existing map refcount mechanism to forestall cleanup of a map until the
cursor iterates past the node.

Signed-off-by: Krister Johansen 
---
 tools/perf/util/callchain.c | 11 +--
 tools/perf/util/callchain.h |  6 ++
 tools/perf/util/hist.c  | 10 ++
 3 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index 4292251..8b610dd 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -437,7 +437,7 @@ fill_node(struct callchain_node *node, struct 
callchain_cursor *cursor)
}
call->ip = cursor_node->ip;
call->ms.sym = cursor_node->sym;
-   call->ms.map = cursor_node->map;
+   call->ms.map = map__get(cursor_node->map);
 
if (cursor_node->branch) {
call->branch_count = 1;
@@ -477,6 +477,7 @@ add_child(struct callchain_node *parent,
 
list_for_each_entry_safe(call, tmp, >val, list) {
list_del(>list);
+   map__zput(call->ms.map);
free(call);
}
free(new);
@@ -761,6 +762,7 @@ merge_chain_branch(struct callchain_cursor *cursor,
list->ms.map, list->ms.sym,
false, NULL, 0, 0);
list_del(>list);
+   map__zput(list->ms.map);
free(list);
}
 
@@ -811,7 +813,8 @@ int callchain_cursor_append(struct callchain_cursor *cursor,
}
 
node->ip = ip;
-   node->map = map;
+   map__zput(node->map);
+   node->map = map__get(map);
node->sym = sym;
node->branch = branch;
node->nr_loop_iter = nr_loop_iter;
@@ -1142,11 +1145,13 @@ static void free_callchain_node(struct callchain_node 
*node)
 
list_for_each_entry_safe(list, tmp, >parent_val, list) {
list_del(>list);
+   map__zput(list->ms.map);
free(list);
}
 
list_for_each_entry_safe(list, tmp, >val, list) {
list_del(>list);
+   map__zput(list->ms.map);
free(list);
}
 
@@ -1210,6 +1215,7 @@ int callchain_node__make_parent_list(struct 
callchain_node *node)
goto out;
*new = *chain;
new->has_children = false;
+   map__get(new->ms.map);
list_add_tail(>list, );
}
parent = parent->parent;
@@ -1230,6 +1236,7 @@ int callchain_node__make_parent_list(struct 
callchain_node *node)
 out:
list_for_each_entry_safe(chain, new, , list) {
list_del(>list);
+   map__zput(chain->ms.map);
free(chain);
}
return -ENOMEM;
diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
index 35c8e37..4f4b60f 100644
--- a/tools/perf/util/callchain.h
+++ b/tools/perf/util/callchain.h
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include "event.h"
+#include "map.h"
 #include "symbol.h"
 
 #define HELP_PAD "\t\t\t\t"
@@ -184,8 +185,13 @@ int callchain_merge(struct callchain_cursor *cursor,
  */
 static inline void callchain_cursor_reset(struct callchain_cursor *cursor)
 {
+   struct callchain_cursor_node *node;
+
cursor->nr = 0;
cursor->last = >first;
+
+   for (node = cursor->first; node != NULL; node = node->next)
+   map__zput(node->map);
 }
 
 int callchain_cursor_append(struct callchain_cursor *cursor, u64 ip,
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 6770a96..9dabbae 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -1,6 +1,7 @@
 #include "util.h"
 #include "build-id.h"
 #include "hist.h"
+#include "map.h"
 #include "session.h"
 #include "sort.h"
 #include "evlist.h"
@@ -1019,6 +1020,12 @@ int hist_entry_iter__add(struct hist_entry_iter *iter, 
struct addr_location *al,
 int max_stack_depth, void *arg)
 {
int err, err2;
+   struct map *alm;
+
+   alm = NULL;
+
+   if (al && al->map)
+   alm = map__get(al->map);
 
err = sample__resolve_callchain(iter->sample, _cursor, 
>parent,
iter->evsel, al, max_stack_depth);
@@ -1058,6 +1065,9 @@ int hist_entry_iter__add(struct hist_entry_iter *iter, 
struct addr_location *al,
if (!err)
err = err2;
 
+   if (alm)
+   map__put(alm);
+
return err;
 }
 
-- 
2.7.4

Re: [v1] i4l: act2000: act2000:- Do not use 'asm/io.h' directly, use 'linux/io.h'.

[Arvind Yadav]

Thanks for your suggestion :).
I have done the changes as per your concern . Please review it.

Thanks :)
-Arvind

On Thursday 05 January 2017 05:35 PM, Greg KH wrote:

On Thu, Jan 05, 2017 at 05:25:05PM +0530, Arvind Yadav wrote:

Please find my comment below.

Where?  What happened to your email quoting?


Thanks
-Arvind

On Thursday 05 January 2017 05:16 PM, Greg KH wrote:

On Thu, Jan 05, 2017 at 04:09:24PM +0530, Arvind Yadav wrote:

Make uniform definition of ioremap, ioremap_wc, ioremap_wt and
ioremap_cache, tree-wide.

That doesn't make much sense, and doesn't match the subject: or the
patch itself.
-- Please refer the commit which is already in main-lined.
commit 2584cf83578c26db144730ef498f4070f82ee3ea

Ah, here it is, please quote stuff correctly.

If you are referring to something else, great, then say so in the commit
itself.  Every commit should be self-explanatory, how am I supposed to
know this.

And this text still doesn't make sense to me, please fix.


And what is with the "[v1]"?
---V1 is stands  for patch set version 1

Please read Documentation/SubmittingPatches for how to properly label
patches, don't make new things up, we have too many different developers
(i.e. 4000+) for everyone to do their own unique thing.  :)

thanks,

greg k-h

Re: [v1] i4l: act2000: act2000:- Do not use 'asm/io.h' directly, use 'linux/io.h'.

[Arvind Yadav]

Thanks for your suggestion :).
I have done the changes as per your concern . Please review it.

Thanks :)
-Arvind

On Thursday 05 January 2017 05:35 PM, Greg KH wrote:

On Thu, Jan 05, 2017 at 05:25:05PM +0530, Arvind Yadav wrote:

Please find my comment below.

Where?  What happened to your email quoting?


Thanks
-Arvind

On Thursday 05 January 2017 05:16 PM, Greg KH wrote:

On Thu, Jan 05, 2017 at 04:09:24PM +0530, Arvind Yadav wrote:

Make uniform definition of ioremap, ioremap_wc, ioremap_wt and
ioremap_cache, tree-wide.

That doesn't make much sense, and doesn't match the subject: or the
patch itself.
-- Please refer the commit which is already in main-lined.
commit 2584cf83578c26db144730ef498f4070f82ee3ea

Ah, here it is, please quote stuff correctly.

If you are referring to something else, great, then say so in the commit
itself.  Every commit should be self-explanatory, how am I supposed to
know this.

And this text still doesn't make sense to me, please fix.


And what is with the "[v1]"?
---V1 is stands  for patch set version 1

Please read Documentation/SubmittingPatches for how to properly label
patches, don't make new things up, we have too many different developers
(i.e. 4000+) for everyone to do their own unique thing.  :)

thanks,

greg k-h

Re: [PATCH v3 1/3] drivers: crypto: Add Support for Octeon-tx CPT Engine

[George Cherian]

Hi Corentin,

Thank you very much for the review.
I was on vacation and now am back, I will fix your comments and send a 
new version.



On 12/21/2016 06:53 PM, Corentin Labbe wrote:

Hello

I have some comment inline

On Wed, Dec 21, 2016 at 11:56:11AM +, george.cher...@cavium.com wrote:

From: George Cherian 

Enable the Physical Function diver for the Cavium Crypto Engine (CPT)


typo driver

okay



found in Octeon-tx series of SoC's. CPT is the Cryptographic Acceleration
Unit. CPT includes microcoded GigaCypher symmetric engines (SEs) and
asymmetric engines (AEs).

Signed-off-by: George Cherian 
Reviewed-by: David Daney 
---
  drivers/crypto/cavium/cpt/Kconfig|  16 +
  drivers/crypto/cavium/cpt/Makefile   |   2 +
  drivers/crypto/cavium/cpt/cpt_common.h   | 158 +++
  drivers/crypto/cavium/cpt/cpt_hw_types.h | 658 +
  drivers/crypto/cavium/cpt/cptpf.h|  69 +++
  drivers/crypto/cavium/cpt/cptpf_main.c   | 703 +++
  drivers/crypto/cavium/cpt/cptpf_mbox.c   | 163 +++
  7 files changed, 1769 insertions(+)
  create mode 100644 drivers/crypto/cavium/cpt/Kconfig
  create mode 100644 drivers/crypto/cavium/cpt/Makefile
  create mode 100644 drivers/crypto/cavium/cpt/cpt_common.h
  create mode 100644 drivers/crypto/cavium/cpt/cpt_hw_types.h
  create mode 100644 drivers/crypto/cavium/cpt/cptpf.h
  create mode 100644 drivers/crypto/cavium/cpt/cptpf_main.c
  create mode 100644 drivers/crypto/cavium/cpt/cptpf_mbox.c

diff --git a/drivers/crypto/cavium/cpt/Kconfig 
b/drivers/crypto/cavium/cpt/Kconfig
new file mode 100644
index 000..247f1cb
--- /dev/null
+++ b/drivers/crypto/cavium/cpt/Kconfig
@@ -0,0 +1,16 @@
+#
+# Cavium crypto device configuration
+#
+
+config CRYPTO_DEV_CPT
+   tristate
+
+config CAVIUM_CPT
+   tristate "Cavium Cryptographic Accelerator driver"
+   depends on ARCH_THUNDER
+   select CRYPTO_DEV_CPT


Could you add some COMPILE_TEST ?


You meant depends on ARCH_THUNDER || COMPILE_TEST?


[...]

+struct microcode {
+   u8 is_mc_valid;
+   u8 is_ae;
+   u8 group;
+   u8 num_cores;
+   u32 code_size;
+   u64 core_mask;
+   u8 version[32];


I see this "32" in some other place, perhaps you could use a define

okay


[...]

+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 


Header need to be sorted

will do


[...]

+static void cpt_disable_cores(struct cpt_device *cpt, u64 coremask,
+ u8 type, u8 grp)
+{
+   u64 pf_exe_ctl;
+   u32 timeout = 0x;
+   u64 grpmask = 0;
+   struct device *dev = >pdev->dev;
+
+   if (type == AE_TYPES)
+   coremask = (coremask << cpt->max_se_cores);
+
+   /* Disengage the cores from groups */
+   grpmask = cpt_read_csr64(cpt->reg_base, CPTX_PF_GX_EN(0, grp));
+   cpt_write_csr64(cpt->reg_base, CPTX_PF_GX_EN(0, grp),
+   (grpmask & ~coremask));
+   udelay(CSR_DELAY);
+   grp = cpt_read_csr64(cpt->reg_base, CPTX_PF_EXEC_BUSY(0));
+   while (grp & coremask) {
+   dev_err(dev, "Cores still busy %llx", coremask);
+   grp = cpt_read_csr64(cpt->reg_base,
+CPTX_PF_EXEC_BUSY(0));
+   if (timeout--)
+   break;


The timeout seems enormous and you will flooding syslog with dev_err()

will reduce.



+   }
+
+   /* Disable the cores */
+   pf_exe_ctl = cpt_read_csr64(cpt->reg_base, CPTX_PF_EXE_CTL(0));
+   cpt_write_csr64(cpt->reg_base, CPTX_PF_EXE_CTL(0),
+   (pf_exe_ctl & ~coremask));
+   udelay(CSR_DELAY);
+}
+
+/*
+ * Enable cores specified by coremask
+ */
+static void cpt_enable_cores(struct cpt_device *cpt, u64 coremask,
+u8 type)
+{
+   u64 pf_exe_ctl;
+
+   if (type == AE_TYPES)
+   coremask = (coremask << cpt->max_se_cores);
+
+   pf_exe_ctl = cpt_read_csr64(cpt->reg_base, CPTX_PF_EXE_CTL(0));
+   cpt_write_csr64(cpt->reg_base, CPTX_PF_EXE_CTL(0),
+   (pf_exe_ctl | coremask));
+   udelay(CSR_DELAY);
+}
+
+static void cpt_configure_group(struct cpt_device *cpt, u8 grp,
+   u64 coremask, u8 type)
+{
+   u64 pf_gx_en = 0;
+
+   if (type == AE_TYPES)
+   coremask = (coremask << cpt->max_se_cores);
+
+   pf_gx_en = cpt_read_csr64(cpt->reg_base, CPTX_PF_GX_EN(0, grp));
+   cpt_write_csr64(cpt->reg_base, CPTX_PF_GX_EN(0, grp),
+   (pf_gx_en | coremask));
+   udelay(CSR_DELAY);
+}
+
+static void cpt_disable_mbox_interrupts(struct cpt_device *cpt)
+{
+   /* Clear mbox(0) interupts for all vfs */
+   cpt_write_csr64(cpt->reg_base, CPTX_PF_MBOX_ENA_W1CX(0, 0), ~0ull);
+}
+
+static void cpt_disable_ecc_interrupts(struct cpt_device 

Re: [PATCH v3 1/3] drivers: crypto: Add Support for Octeon-tx CPT Engine

[George Cherian]

Hi Corentin,

Thank you very much for the review.
I was on vacation and now am back, I will fix your comments and send a 
new version.



On 12/21/2016 06:53 PM, Corentin Labbe wrote:

Hello

I have some comment inline

On Wed, Dec 21, 2016 at 11:56:11AM +, george.cher...@cavium.com wrote:

From: George Cherian 

Enable the Physical Function diver for the Cavium Crypto Engine (CPT)


typo driver

okay



found in Octeon-tx series of SoC's. CPT is the Cryptographic Acceleration
Unit. CPT includes microcoded GigaCypher symmetric engines (SEs) and
asymmetric engines (AEs).

Signed-off-by: George Cherian 
Reviewed-by: David Daney 
---
  drivers/crypto/cavium/cpt/Kconfig|  16 +
  drivers/crypto/cavium/cpt/Makefile   |   2 +
  drivers/crypto/cavium/cpt/cpt_common.h   | 158 +++
  drivers/crypto/cavium/cpt/cpt_hw_types.h | 658 +
  drivers/crypto/cavium/cpt/cptpf.h|  69 +++
  drivers/crypto/cavium/cpt/cptpf_main.c   | 703 +++
  drivers/crypto/cavium/cpt/cptpf_mbox.c   | 163 +++
  7 files changed, 1769 insertions(+)
  create mode 100644 drivers/crypto/cavium/cpt/Kconfig
  create mode 100644 drivers/crypto/cavium/cpt/Makefile
  create mode 100644 drivers/crypto/cavium/cpt/cpt_common.h
  create mode 100644 drivers/crypto/cavium/cpt/cpt_hw_types.h
  create mode 100644 drivers/crypto/cavium/cpt/cptpf.h
  create mode 100644 drivers/crypto/cavium/cpt/cptpf_main.c
  create mode 100644 drivers/crypto/cavium/cpt/cptpf_mbox.c

diff --git a/drivers/crypto/cavium/cpt/Kconfig 
b/drivers/crypto/cavium/cpt/Kconfig
new file mode 100644
index 000..247f1cb
--- /dev/null
+++ b/drivers/crypto/cavium/cpt/Kconfig
@@ -0,0 +1,16 @@
+#
+# Cavium crypto device configuration
+#
+
+config CRYPTO_DEV_CPT
+   tristate
+
+config CAVIUM_CPT
+   tristate "Cavium Cryptographic Accelerator driver"
+   depends on ARCH_THUNDER
+   select CRYPTO_DEV_CPT


Could you add some COMPILE_TEST ?


You meant depends on ARCH_THUNDER || COMPILE_TEST?


[...]

+struct microcode {
+   u8 is_mc_valid;
+   u8 is_ae;
+   u8 group;
+   u8 num_cores;
+   u32 code_size;
+   u64 core_mask;
+   u8 version[32];


I see this "32" in some other place, perhaps you could use a define

okay


[...]

+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 


Header need to be sorted

will do


[...]

+static void cpt_disable_cores(struct cpt_device *cpt, u64 coremask,
+ u8 type, u8 grp)
+{
+   u64 pf_exe_ctl;
+   u32 timeout = 0x;
+   u64 grpmask = 0;
+   struct device *dev = >pdev->dev;
+
+   if (type == AE_TYPES)
+   coremask = (coremask << cpt->max_se_cores);
+
+   /* Disengage the cores from groups */
+   grpmask = cpt_read_csr64(cpt->reg_base, CPTX_PF_GX_EN(0, grp));
+   cpt_write_csr64(cpt->reg_base, CPTX_PF_GX_EN(0, grp),
+   (grpmask & ~coremask));
+   udelay(CSR_DELAY);
+   grp = cpt_read_csr64(cpt->reg_base, CPTX_PF_EXEC_BUSY(0));
+   while (grp & coremask) {
+   dev_err(dev, "Cores still busy %llx", coremask);
+   grp = cpt_read_csr64(cpt->reg_base,
+CPTX_PF_EXEC_BUSY(0));
+   if (timeout--)
+   break;


The timeout seems enormous and you will flooding syslog with dev_err()

will reduce.



+   }
+
+   /* Disable the cores */
+   pf_exe_ctl = cpt_read_csr64(cpt->reg_base, CPTX_PF_EXE_CTL(0));
+   cpt_write_csr64(cpt->reg_base, CPTX_PF_EXE_CTL(0),
+   (pf_exe_ctl & ~coremask));
+   udelay(CSR_DELAY);
+}
+
+/*
+ * Enable cores specified by coremask
+ */
+static void cpt_enable_cores(struct cpt_device *cpt, u64 coremask,
+u8 type)
+{
+   u64 pf_exe_ctl;
+
+   if (type == AE_TYPES)
+   coremask = (coremask << cpt->max_se_cores);
+
+   pf_exe_ctl = cpt_read_csr64(cpt->reg_base, CPTX_PF_EXE_CTL(0));
+   cpt_write_csr64(cpt->reg_base, CPTX_PF_EXE_CTL(0),
+   (pf_exe_ctl | coremask));
+   udelay(CSR_DELAY);
+}
+
+static void cpt_configure_group(struct cpt_device *cpt, u8 grp,
+   u64 coremask, u8 type)
+{
+   u64 pf_gx_en = 0;
+
+   if (type == AE_TYPES)
+   coremask = (coremask << cpt->max_se_cores);
+
+   pf_gx_en = cpt_read_csr64(cpt->reg_base, CPTX_PF_GX_EN(0, grp));
+   cpt_write_csr64(cpt->reg_base, CPTX_PF_GX_EN(0, grp),
+   (pf_gx_en | coremask));
+   udelay(CSR_DELAY);
+}
+
+static void cpt_disable_mbox_interrupts(struct cpt_device *cpt)
+{
+   /* Clear mbox(0) interupts for all vfs */
+   cpt_write_csr64(cpt->reg_base, CPTX_PF_MBOX_ENA_W1CX(0, 0), ~0ull);
+}
+
+static void cpt_disable_ecc_interrupts(struct cpt_device *cpt)
+{
+   /* Clear ecc(0) interupts for all vfs */
+   

[PATCH v2 02/2] i4l: act2000: act2000:- Do not use 'asm/io.h' directly, use 'linux/io.h'.

[Arvind Yadav]

'commit 2584cf83578c ("arch, drivers: don't
include  directly, use  instead")'
Make uniform definition of ioremap, ioremap_wc, ioremap_wt and
ioremap_cache, tree-wide.

Signed-off-by: Arvind Yadav 
---
 drivers/staging/i4l/act2000/act2000.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/i4l/act2000/act2000.h 
b/drivers/staging/i4l/act2000/act2000.h
index 321d437..e372ff5 100644
--- a/drivers/staging/i4l/act2000/act2000.h
+++ b/drivers/staging/i4l/act2000/act2000.h
@@ -70,7 +70,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
-- 
1.9.1

[PATCH v2 02/2] i4l: act2000: act2000:- Do not use 'asm/io.h' directly, use 'linux/io.h'.

[Arvind Yadav]

'commit 2584cf83578c ("arch, drivers: don't
include  directly, use  instead")'
Make uniform definition of ioremap, ioremap_wc, ioremap_wt and
ioremap_cache, tree-wide.

Signed-off-by: Arvind Yadav 
---
 drivers/staging/i4l/act2000/act2000.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/i4l/act2000/act2000.h 
b/drivers/staging/i4l/act2000/act2000.h
index 321d437..e372ff5 100644
--- a/drivers/staging/i4l/act2000/act2000.h
+++ b/drivers/staging/i4l/act2000/act2000.h
@@ -70,7 +70,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
-- 
1.9.1

Re: [PATCH v2 3/4] ARM64: dts: exynos5433: use macros for pinctrl configuration on Exynos5433

[Krzysztof Kozlowski]

On Fri, Jan 06, 2017 at 11:23:43AM +0900, Andi Shyti wrote:
> Hi Krzysztof,
> 
> > Andi,
> > Please fix missing Signed-off-by and resend with Linus' tags for #1 and
> > #2 and with other accumulated tags.
> 
> patch #1 has already been merged in mainline:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1259feddd0f83649d5c48d730c140b4f7f3fa288
> 
> and patch #2 is in LinusW's -next branch.

Yes, but it is gone from devel so I suppose it will be removed from
for-next in the future as well.

> does it still make sense to send them again? If you want I can
> send again patch 3 and 4 as independent patches with Chanwoo's
> review (the only tags).

No, no need. I wanted resend only because of #1 but it is merged as you
said.

Best regards,
Krzysztof

Re: [PATCH v2 3/4] ARM64: dts: exynos5433: use macros for pinctrl configuration on Exynos5433

[Krzysztof Kozlowski]

On Fri, Jan 06, 2017 at 11:23:43AM +0900, Andi Shyti wrote:
> Hi Krzysztof,
> 
> > Andi,
> > Please fix missing Signed-off-by and resend with Linus' tags for #1 and
> > #2 and with other accumulated tags.
> 
> patch #1 has already been merged in mainline:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1259feddd0f83649d5c48d730c140b4f7f3fa288
> 
> and patch #2 is in LinusW's -next branch.

Yes, but it is gone from devel so I suppose it will be removed from
for-next in the future as well.

> does it still make sense to send them again? If you want I can
> send again patch 3 and 4 as independent patches with Chanwoo's
> review (the only tags).

No, no need. I wanted resend only because of #1 but it is merged as you
said.

Best regards,
Krzysztof

Re: [PATCH 2/2] ocfs2: fix deadlocks when taking inode lock at vfs entry points

[Joseph Qi]

Hi Eric,


On 17/1/5 23:31, Eric Ren wrote:

Commit 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()")
results in a deadlock, as the author "Tariq Saeed" realized shortly
after the patch was merged. The discussion happened here
(https://oss.oracle.com/pipermail/ocfs2-devel/2015-September/011085.html).

The reason why taking cluster inode lock at vfs entry points opens up
a self deadlock window, is explained in the previous patch of this
series.

So far, we have seen two different code paths that have this issue.
1. do_sys_open
  may_open
   inode_permission
ocfs2_permission
 ocfs2_inode_lock() <=== take PR
  generic_permission
   get_acl
ocfs2_iop_get_acl
 ocfs2_inode_lock() <=== take PR
2. fchmod|fchmodat
 chmod_common
  notify_change
   ocfs2_setattr <=== take EX
posix_acl_chmod
 get_acl
  ocfs2_iop_get_acl <=== take PR
 ocfs2_iop_set_acl <=== take EX

Fixes them by adding the tracking logic (in the previous patch) for
these funcs above, ocfs2_permission(), ocfs2_iop_[set|get]_acl(),
ocfs2_setattr().
As described cases above, shall we just add the tracking logic only for 
set/get_acl()?


Thanks,
Joseph


Signed-off-by: Eric Ren 
---
  fs/ocfs2/acl.c  | 39 ++-
  fs/ocfs2/file.c | 44 ++--
  2 files changed, 68 insertions(+), 15 deletions(-)

diff --git a/fs/ocfs2/acl.c b/fs/ocfs2/acl.c
index bed1fcb..c539890 100644
--- a/fs/ocfs2/acl.c
+++ b/fs/ocfs2/acl.c
@@ -284,16 +284,31 @@ int ocfs2_iop_set_acl(struct inode *inode, struct 
posix_acl *acl, int type)
  {
struct buffer_head *bh = NULL;
int status = 0;
-
-   status = ocfs2_inode_lock(inode, , 1);
+   int arg_flags = 0, has_locked;
+   struct ocfs2_holder oh;
+   struct ocfs2_lock_res *lockres;
+
+   lockres = _I(inode)->ip_inode_lockres;
+   has_locked = (ocfs2_is_locked_by_me(lockres) != NULL);
+   if (has_locked)
+   arg_flags = OCFS2_META_LOCK_GETBH;
+   status = ocfs2_inode_lock_full(inode, , 1, arg_flags);
if (status < 0) {
if (status != -ENOENT)
mlog_errno(status);
return status;
}
+   if (!has_locked)
+   ocfs2_add_holder(lockres, );
+
status = ocfs2_set_acl(NULL, inode, bh, type, acl, NULL, NULL);
-   ocfs2_inode_unlock(inode, 1);
+
+   if (!has_locked) {
+   ocfs2_remove_holder(lockres, );
+   ocfs2_inode_unlock(inode, 1);
+   }
brelse(bh);
+
return status;
  }
  
@@ -303,21 +318,35 @@ struct posix_acl *ocfs2_iop_get_acl(struct inode *inode, int type)

struct buffer_head *di_bh = NULL;
struct posix_acl *acl;
int ret;
+   int arg_flags = 0, has_locked;
+   struct ocfs2_holder oh;
+   struct ocfs2_lock_res *lockres;
  
  	osb = OCFS2_SB(inode->i_sb);

if (!(osb->s_mount_opt & OCFS2_MOUNT_POSIX_ACL))
return NULL;
-   ret = ocfs2_inode_lock(inode, _bh, 0);
+
+   lockres = _I(inode)->ip_inode_lockres;
+   has_locked = (ocfs2_is_locked_by_me(lockres) != NULL);
+   if (has_locked)
+   arg_flags = OCFS2_META_LOCK_GETBH;
+   ret = ocfs2_inode_lock_full(inode, _bh, 0, arg_flags);
if (ret < 0) {
if (ret != -ENOENT)
mlog_errno(ret);
return ERR_PTR(ret);
}
+   if (!has_locked)
+   ocfs2_add_holder(lockres, );
  
  	acl = ocfs2_get_acl_nolock(inode, type, di_bh);
  
-	ocfs2_inode_unlock(inode, 0);

+   if (!has_locked) {
+   ocfs2_remove_holder(lockres, );
+   ocfs2_inode_unlock(inode, 0);
+   }
brelse(di_bh);
+
return acl;
  }
  
diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c

index c488965..62be75d 100644
--- a/fs/ocfs2/file.c
+++ b/fs/ocfs2/file.c
@@ -1138,6 +1138,9 @@ int ocfs2_setattr(struct dentry *dentry, struct iattr 
*attr)
handle_t *handle = NULL;
struct dquot *transfer_to[MAXQUOTAS] = { };
int qtype;
+   int arg_flags = 0, had_lock;
+   struct ocfs2_holder oh;
+   struct ocfs2_lock_res *lockres;
  
  	trace_ocfs2_setattr(inode, dentry,

(unsigned long long)OCFS2_I(inode)->ip_blkno,
@@ -1173,13 +1176,20 @@ int ocfs2_setattr(struct dentry *dentry, struct iattr 
*attr)
}
}
  
-	status = ocfs2_inode_lock(inode, , 1);

+   lockres = _I(inode)->ip_inode_lockres;
+   had_lock = (ocfs2_is_locked_by_me(lockres) != NULL);
+   if (had_lock)
+   arg_flags = OCFS2_META_LOCK_GETBH;
+   status = ocfs2_inode_lock_full(inode, , 1, arg_flags);
if (status < 0) {
if (status != -ENOENT)
mlog_errno(status);
goto bail_unlock_rw;
}
-   

Re: [PATCH 2/2] ocfs2: fix deadlocks when taking inode lock at vfs entry points

[Joseph Qi]

Hi Eric,


On 17/1/5 23:31, Eric Ren wrote:

Commit 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()")
results in a deadlock, as the author "Tariq Saeed" realized shortly
after the patch was merged. The discussion happened here
(https://oss.oracle.com/pipermail/ocfs2-devel/2015-September/011085.html).

The reason why taking cluster inode lock at vfs entry points opens up
a self deadlock window, is explained in the previous patch of this
series.

So far, we have seen two different code paths that have this issue.
1. do_sys_open
  may_open
   inode_permission
ocfs2_permission
 ocfs2_inode_lock() <=== take PR
  generic_permission
   get_acl
ocfs2_iop_get_acl
 ocfs2_inode_lock() <=== take PR
2. fchmod|fchmodat
 chmod_common
  notify_change
   ocfs2_setattr <=== take EX
posix_acl_chmod
 get_acl
  ocfs2_iop_get_acl <=== take PR
 ocfs2_iop_set_acl <=== take EX

Fixes them by adding the tracking logic (in the previous patch) for
these funcs above, ocfs2_permission(), ocfs2_iop_[set|get]_acl(),
ocfs2_setattr().
As described cases above, shall we just add the tracking logic only for 
set/get_acl()?


Thanks,
Joseph


Signed-off-by: Eric Ren 
---
  fs/ocfs2/acl.c  | 39 ++-
  fs/ocfs2/file.c | 44 ++--
  2 files changed, 68 insertions(+), 15 deletions(-)

diff --git a/fs/ocfs2/acl.c b/fs/ocfs2/acl.c
index bed1fcb..c539890 100644
--- a/fs/ocfs2/acl.c
+++ b/fs/ocfs2/acl.c
@@ -284,16 +284,31 @@ int ocfs2_iop_set_acl(struct inode *inode, struct 
posix_acl *acl, int type)
  {
struct buffer_head *bh = NULL;
int status = 0;
-
-   status = ocfs2_inode_lock(inode, , 1);
+   int arg_flags = 0, has_locked;
+   struct ocfs2_holder oh;
+   struct ocfs2_lock_res *lockres;
+
+   lockres = _I(inode)->ip_inode_lockres;
+   has_locked = (ocfs2_is_locked_by_me(lockres) != NULL);
+   if (has_locked)
+   arg_flags = OCFS2_META_LOCK_GETBH;
+   status = ocfs2_inode_lock_full(inode, , 1, arg_flags);
if (status < 0) {
if (status != -ENOENT)
mlog_errno(status);
return status;
}
+   if (!has_locked)
+   ocfs2_add_holder(lockres, );
+
status = ocfs2_set_acl(NULL, inode, bh, type, acl, NULL, NULL);
-   ocfs2_inode_unlock(inode, 1);
+
+   if (!has_locked) {
+   ocfs2_remove_holder(lockres, );
+   ocfs2_inode_unlock(inode, 1);
+   }
brelse(bh);
+
return status;
  }
  
@@ -303,21 +318,35 @@ struct posix_acl *ocfs2_iop_get_acl(struct inode *inode, int type)

struct buffer_head *di_bh = NULL;
struct posix_acl *acl;
int ret;
+   int arg_flags = 0, has_locked;
+   struct ocfs2_holder oh;
+   struct ocfs2_lock_res *lockres;
  
  	osb = OCFS2_SB(inode->i_sb);

if (!(osb->s_mount_opt & OCFS2_MOUNT_POSIX_ACL))
return NULL;
-   ret = ocfs2_inode_lock(inode, _bh, 0);
+
+   lockres = _I(inode)->ip_inode_lockres;
+   has_locked = (ocfs2_is_locked_by_me(lockres) != NULL);
+   if (has_locked)
+   arg_flags = OCFS2_META_LOCK_GETBH;
+   ret = ocfs2_inode_lock_full(inode, _bh, 0, arg_flags);
if (ret < 0) {
if (ret != -ENOENT)
mlog_errno(ret);
return ERR_PTR(ret);
}
+   if (!has_locked)
+   ocfs2_add_holder(lockres, );
  
  	acl = ocfs2_get_acl_nolock(inode, type, di_bh);
  
-	ocfs2_inode_unlock(inode, 0);

+   if (!has_locked) {
+   ocfs2_remove_holder(lockres, );
+   ocfs2_inode_unlock(inode, 0);
+   }
brelse(di_bh);
+
return acl;
  }
  
diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c

index c488965..62be75d 100644
--- a/fs/ocfs2/file.c
+++ b/fs/ocfs2/file.c
@@ -1138,6 +1138,9 @@ int ocfs2_setattr(struct dentry *dentry, struct iattr 
*attr)
handle_t *handle = NULL;
struct dquot *transfer_to[MAXQUOTAS] = { };
int qtype;
+   int arg_flags = 0, had_lock;
+   struct ocfs2_holder oh;
+   struct ocfs2_lock_res *lockres;
  
  	trace_ocfs2_setattr(inode, dentry,

(unsigned long long)OCFS2_I(inode)->ip_blkno,
@@ -1173,13 +1176,20 @@ int ocfs2_setattr(struct dentry *dentry, struct iattr 
*attr)
}
}
  
-	status = ocfs2_inode_lock(inode, , 1);

+   lockres = _I(inode)->ip_inode_lockres;
+   had_lock = (ocfs2_is_locked_by_me(lockres) != NULL);
+   if (had_lock)
+   arg_flags = OCFS2_META_LOCK_GETBH;
+   status = ocfs2_inode_lock_full(inode, , 1, arg_flags);
if (status < 0) {
if (status != -ENOENT)
mlog_errno(status);
goto bail_unlock_rw;
}
-   inode_locked = 1;
+

[PATCH v4] rfkill: Add rfkill-any LED trigger

[Michał Kępień]

Add a new "global" (i.e. not per-rfkill device) LED trigger, rfkill-any,
which may be useful on laptops with a single "radio LED" and multiple
radio transmitters.  The trigger is meant to turn a LED on whenever
there is at least one radio transmitter active and turn it off
otherwise.

Signed-off-by: Michał Kępień 
---
Changes from v3:

  - Revert introducing a new bitfield and instead defer LED event firing
to a work queue to prevent conditional locking and ensure the
trigger can really be used from any context.  This also voids the
need to take rfkill_global_mutex before calling rfkill_set_block()
in rfkill_resume().

Changes from v2:

  - Handle the global mutex properly when rfkill_set_{hw,sw}_state() or
rfkill_set_states() is called from within an rfkill callback.  v2
always tried to lock the global mutex in such a case, which led to a
deadlock when an rfkill driver called one of the above functions
from its query or set_block callback.  This is solved by defining a
new bitfield, RFKILL_BLOCK_SW_HASLOCK, which is set before the above
callbacks are invoked and cleared afterwards; the functions listed
above use this bitfield to tell rfkill_any_led_trigger_event()
whether the global mutex is currently held or not.
RFKILL_BLOCK_SW_SETCALL cannot be reused for this purpose as setting
it before invoking the query callback would cause any calls to
rfkill_set_sw_state() made from within that callback to work on
RFKILL_BLOCK_SW_PREV instead of RFKILL_BLOCK_SW and thus change the
way rfkill_set_block() behaves.

  - As rfkill_any_led_trigger_event() now takes a boolean argument which
tells it whether the global mutex was already taken by the caller,
all calls to __rfkill_any_led_trigger_event() outside
rfkill_any_led_trigger_event() have been replaced with calls to
rfkill_any_led_trigger_event(true).

Changes from v1:

  - take rfkill_global_mutex before calling rfkill_set_block() in
rfkill_resume(); the need for doing this was previously obviated by
908209c ("rfkill: don't impose global states on resume"), but given
that __rfkill_any_led_trigger_event() is called from
rfkill_set_block() unconditionally, each caller of the latter needs
to take care of locking rfkill_global_mutex,

  - declare __rfkill_any_led_trigger_event() even when
CONFIG_RFKILL_LEDS=n to prevent implicit declaration errors,

  - remove the #ifdef surrounding rfkill_any_led_trigger_{,un}register()
calls to prevent compilation warnings about functions and a label
being defined but not used,

  - move the rfkill_any_led_trigger_register() call in rfkill_init()
before the rfkill_handler_init() call to avoid the need to call
rfkill_handler_exit() from rfkill_init() and thus prevent a section
mismatch.

 net/rfkill/core.c | 72 ++-
 1 file changed, 71 insertions(+), 1 deletion(-)

diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index afa4f71b4c7b..2064c3a35ef8 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -176,6 +176,50 @@ static void rfkill_led_trigger_unregister(struct rfkill 
*rfkill)
 {
led_trigger_unregister(>led_trigger);
 }
+
+static struct led_trigger rfkill_any_led_trigger;
+static struct work_struct rfkill_any_work;
+
+static void rfkill_any_led_trigger_worker(struct work_struct *work)
+{
+   enum led_brightness brightness = LED_OFF;
+   struct rfkill *rfkill;
+
+   mutex_lock(_global_mutex);
+   list_for_each_entry(rfkill, _list, node) {
+   if (!(rfkill->state & RFKILL_BLOCK_ANY)) {
+   brightness = LED_FULL;
+   break;
+   }
+   }
+   mutex_unlock(_global_mutex);
+
+   led_trigger_event(_any_led_trigger, brightness);
+}
+
+static void rfkill_any_led_trigger_event(void)
+{
+   schedule_work(_any_work);
+}
+
+static void rfkill_any_led_trigger_activate(struct led_classdev *led_cdev)
+{
+   rfkill_any_led_trigger_event();
+}
+
+static int rfkill_any_led_trigger_register(void)
+{
+   INIT_WORK(_any_work, rfkill_any_led_trigger_worker);
+   rfkill_any_led_trigger.name = "rfkill-any";
+   rfkill_any_led_trigger.activate = rfkill_any_led_trigger_activate;
+   return led_trigger_register(_any_led_trigger);
+}
+
+static void rfkill_any_led_trigger_unregister(void)
+{
+   led_trigger_unregister(_any_led_trigger);
+   cancel_work_sync(_any_work);
+}
 #else
 static void rfkill_led_trigger_event(struct rfkill *rfkill)
 {
@@ -189,6 +233,19 @@ static inline int rfkill_led_trigger_register(struct 
rfkill *rfkill)
 static inline void rfkill_led_trigger_unregister(struct rfkill *rfkill)
 {
 }
+
+static void rfkill_any_led_trigger_event(void)
+{
+}
+
+static int rfkill_any_led_trigger_register(void)
+{
+   return 0;
+}
+
+static void rfkill_any_led_trigger_unregister(void)
+{
+}
 #endif /* CONFIG_RFKILL_LEDS 

[PATCH v4] rfkill: Add rfkill-any LED trigger

[Michał Kępień]

Add a new "global" (i.e. not per-rfkill device) LED trigger, rfkill-any,
which may be useful on laptops with a single "radio LED" and multiple
radio transmitters.  The trigger is meant to turn a LED on whenever
there is at least one radio transmitter active and turn it off
otherwise.

Signed-off-by: Michał Kępień 
---
Changes from v3:

  - Revert introducing a new bitfield and instead defer LED event firing
to a work queue to prevent conditional locking and ensure the
trigger can really be used from any context.  This also voids the
need to take rfkill_global_mutex before calling rfkill_set_block()
in rfkill_resume().

Changes from v2:

  - Handle the global mutex properly when rfkill_set_{hw,sw}_state() or
rfkill_set_states() is called from within an rfkill callback.  v2
always tried to lock the global mutex in such a case, which led to a
deadlock when an rfkill driver called one of the above functions
from its query or set_block callback.  This is solved by defining a
new bitfield, RFKILL_BLOCK_SW_HASLOCK, which is set before the above
callbacks are invoked and cleared afterwards; the functions listed
above use this bitfield to tell rfkill_any_led_trigger_event()
whether the global mutex is currently held or not.
RFKILL_BLOCK_SW_SETCALL cannot be reused for this purpose as setting
it before invoking the query callback would cause any calls to
rfkill_set_sw_state() made from within that callback to work on
RFKILL_BLOCK_SW_PREV instead of RFKILL_BLOCK_SW and thus change the
way rfkill_set_block() behaves.

  - As rfkill_any_led_trigger_event() now takes a boolean argument which
tells it whether the global mutex was already taken by the caller,
all calls to __rfkill_any_led_trigger_event() outside
rfkill_any_led_trigger_event() have been replaced with calls to
rfkill_any_led_trigger_event(true).

Changes from v1:

  - take rfkill_global_mutex before calling rfkill_set_block() in
rfkill_resume(); the need for doing this was previously obviated by
908209c ("rfkill: don't impose global states on resume"), but given
that __rfkill_any_led_trigger_event() is called from
rfkill_set_block() unconditionally, each caller of the latter needs
to take care of locking rfkill_global_mutex,

  - declare __rfkill_any_led_trigger_event() even when
CONFIG_RFKILL_LEDS=n to prevent implicit declaration errors,

  - remove the #ifdef surrounding rfkill_any_led_trigger_{,un}register()
calls to prevent compilation warnings about functions and a label
being defined but not used,

  - move the rfkill_any_led_trigger_register() call in rfkill_init()
before the rfkill_handler_init() call to avoid the need to call
rfkill_handler_exit() from rfkill_init() and thus prevent a section
mismatch.

 net/rfkill/core.c | 72 ++-
 1 file changed, 71 insertions(+), 1 deletion(-)

diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index afa4f71b4c7b..2064c3a35ef8 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -176,6 +176,50 @@ static void rfkill_led_trigger_unregister(struct rfkill 
*rfkill)
 {
led_trigger_unregister(>led_trigger);
 }
+
+static struct led_trigger rfkill_any_led_trigger;
+static struct work_struct rfkill_any_work;
+
+static void rfkill_any_led_trigger_worker(struct work_struct *work)
+{
+   enum led_brightness brightness = LED_OFF;
+   struct rfkill *rfkill;
+
+   mutex_lock(_global_mutex);
+   list_for_each_entry(rfkill, _list, node) {
+   if (!(rfkill->state & RFKILL_BLOCK_ANY)) {
+   brightness = LED_FULL;
+   break;
+   }
+   }
+   mutex_unlock(_global_mutex);
+
+   led_trigger_event(_any_led_trigger, brightness);
+}
+
+static void rfkill_any_led_trigger_event(void)
+{
+   schedule_work(_any_work);
+}
+
+static void rfkill_any_led_trigger_activate(struct led_classdev *led_cdev)
+{
+   rfkill_any_led_trigger_event();
+}
+
+static int rfkill_any_led_trigger_register(void)
+{
+   INIT_WORK(_any_work, rfkill_any_led_trigger_worker);
+   rfkill_any_led_trigger.name = "rfkill-any";
+   rfkill_any_led_trigger.activate = rfkill_any_led_trigger_activate;
+   return led_trigger_register(_any_led_trigger);
+}
+
+static void rfkill_any_led_trigger_unregister(void)
+{
+   led_trigger_unregister(_any_led_trigger);
+   cancel_work_sync(_any_work);
+}
 #else
 static void rfkill_led_trigger_event(struct rfkill *rfkill)
 {
@@ -189,6 +233,19 @@ static inline int rfkill_led_trigger_register(struct 
rfkill *rfkill)
 static inline void rfkill_led_trigger_unregister(struct rfkill *rfkill)
 {
 }
+
+static void rfkill_any_led_trigger_event(void)
+{
+}
+
+static int rfkill_any_led_trigger_register(void)
+{
+   return 0;
+}
+
+static void rfkill_any_led_trigger_unregister(void)
+{
+}
 #endif /* CONFIG_RFKILL_LEDS */
 
 static void 

Re: [PATCH 1/2] ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock

[Joseph Qi]

Hi Eric,


On 17/1/5 23:31, Eric Ren wrote:

We are in the situation that we have to avoid recursive cluster locking,
but there is no way to check if a cluster lock has been taken by a
precess already.

Mostly, we can avoid recursive locking by writing code carefully.
However, we found that it's very hard to handle the routines that
are invoked directly by vfs code. For instance:

const struct inode_operations ocfs2_file_iops = {
 .permission = ocfs2_permission,
 .get_acl= ocfs2_iop_get_acl,
 .set_acl= ocfs2_iop_set_acl,
};

Both ocfs2_permission() and ocfs2_iop_get_acl() call ocfs2_inode_lock(PR):
do_sys_open
  may_open
   inode_permission
ocfs2_permission
 ocfs2_inode_lock() <=== first time
  generic_permission
   get_acl
ocfs2_iop_get_acl
ocfs2_inode_lock() <=== recursive one

A deadlock will occur if a remote EX request comes in between two
of ocfs2_inode_lock(). Briefly describe how the deadlock is formed:

On one hand, OCFS2_LOCK_BLOCKED flag of this lockres is set in
BAST(ocfs2_generic_handle_bast) when downconvert is started
on behalf of the remote EX lock request. Another hand, the recursive
cluster lock (the second one) will be blocked in in __ocfs2_cluster_lock()
because of OCFS2_LOCK_BLOCKED. But, the downconvert never complete, why?
because there is no chance for the first cluster lock on this node to be
unlocked - we block ourselves in the code path.

The idea to fix this issue is mostly taken from gfs2 code.
1. introduce a new field: struct ocfs2_lock_res.l_holders, to
keep track of the processes' pid  who has taken the cluster lock
of this lock resource;
2. introduce a new flag for ocfs2_inode_lock_full: OCFS2_META_LOCK_GETBH;
it means just getting back disk inode bh for us if we've got cluster lock.
3. export a helper: ocfs2_is_locked_by_me() is used to check if we
have got the cluster lock in the upper code path.

The tracking logic should be used by some of the ocfs2 vfs's callbacks,
to solve the recursive locking issue cuased by the fact that vfs routines
can call into each other.

The performance penalty of processing the holder list should only be seen
at a few cases where the tracking logic is used, such as get/set acl.

You may ask what if the first time we got a PR lock, and the second time
we want a EX lock? fortunately, this case never happens in the real world,
as far as I can see, including permission check, (get|set)_(acl|attr), and
the gfs2 code also do so.

Signed-off-by: Eric Ren 
---
  fs/ocfs2/dlmglue.c | 47 ---
  fs/ocfs2/dlmglue.h | 18 ++
  fs/ocfs2/ocfs2.h   |  1 +
  3 files changed, 63 insertions(+), 3 deletions(-)

diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
index 83d576f..500bda4 100644
--- a/fs/ocfs2/dlmglue.c
+++ b/fs/ocfs2/dlmglue.c
@@ -532,6 +532,7 @@ void ocfs2_lock_res_init_once(struct ocfs2_lock_res *res)
init_waitqueue_head(>l_event);
INIT_LIST_HEAD(>l_blocked_list);
INIT_LIST_HEAD(>l_mask_waiters);
+   INIT_LIST_HEAD(>l_holders);
  }
  
  void ocfs2_inode_lock_res_init(struct ocfs2_lock_res *res,

@@ -749,6 +750,45 @@ void ocfs2_lock_res_free(struct ocfs2_lock_res *res)
res->l_flags = 0UL;
  }
  
+inline void ocfs2_add_holder(struct ocfs2_lock_res *lockres,

+  struct ocfs2_holder *oh)
+{
+   INIT_LIST_HEAD(>oh_list);
+   oh->oh_owner_pid =  get_pid(task_pid(current));
+
+   spin_lock(>l_lock);
+   list_add_tail(>oh_list, >l_holders);
+   spin_unlock(>l_lock);
+}
+
+inline void ocfs2_remove_holder(struct ocfs2_lock_res *lockres,
+  struct ocfs2_holder *oh)
+{
+   spin_lock(>l_lock);
+   list_del(>oh_list);
+   spin_unlock(>l_lock);
+
+   put_pid(oh->oh_owner_pid);
+}
+
+inline struct ocfs2_holder *ocfs2_is_locked_by_me(struct ocfs2_lock_res 
*lockres)
+{
+   struct ocfs2_holder *oh;
+   struct pid *pid;
+
+   /* look in the list of holders for one with the current task as owner */
+   spin_lock(>l_lock);
+   pid = task_pid(current);
+   list_for_each_entry(oh, >l_holders, oh_list) {
+   if (oh->oh_owner_pid == pid)
+   goto out;
+   }
+   oh = NULL;
+out:
+   spin_unlock(>l_lock);
+   return oh;
+}
Since this ocfs2_holder won't be used in the caller, I suggest just 
return a bool value here.

Something like:
spin_lock();
list_for_each_entry() {
if (oh->oh_owner_pid == pid) {
spin_unlock();
return 1;
}
}
spin_unlock();
return 0;

Thanks,
Joseph

+
  static inline void ocfs2_inc_holders(struct ocfs2_lock_res *lockres,
 int level)
  {
@@ -2333,8 +2373,9 @@ int ocfs2_inode_lock_full_nested(struct inode *inode,
goto getbh;
}
  
-	if (ocfs2_mount_local(osb))

-   goto local;
+   if ((arg_flags & 

Re: [PATCH 1/2] ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock

[Joseph Qi]

Hi Eric,


On 17/1/5 23:31, Eric Ren wrote:

We are in the situation that we have to avoid recursive cluster locking,
but there is no way to check if a cluster lock has been taken by a
precess already.

Mostly, we can avoid recursive locking by writing code carefully.
However, we found that it's very hard to handle the routines that
are invoked directly by vfs code. For instance:

const struct inode_operations ocfs2_file_iops = {
 .permission = ocfs2_permission,
 .get_acl= ocfs2_iop_get_acl,
 .set_acl= ocfs2_iop_set_acl,
};

Both ocfs2_permission() and ocfs2_iop_get_acl() call ocfs2_inode_lock(PR):
do_sys_open
  may_open
   inode_permission
ocfs2_permission
 ocfs2_inode_lock() <=== first time
  generic_permission
   get_acl
ocfs2_iop_get_acl
ocfs2_inode_lock() <=== recursive one

A deadlock will occur if a remote EX request comes in between two
of ocfs2_inode_lock(). Briefly describe how the deadlock is formed:

On one hand, OCFS2_LOCK_BLOCKED flag of this lockres is set in
BAST(ocfs2_generic_handle_bast) when downconvert is started
on behalf of the remote EX lock request. Another hand, the recursive
cluster lock (the second one) will be blocked in in __ocfs2_cluster_lock()
because of OCFS2_LOCK_BLOCKED. But, the downconvert never complete, why?
because there is no chance for the first cluster lock on this node to be
unlocked - we block ourselves in the code path.

The idea to fix this issue is mostly taken from gfs2 code.
1. introduce a new field: struct ocfs2_lock_res.l_holders, to
keep track of the processes' pid  who has taken the cluster lock
of this lock resource;
2. introduce a new flag for ocfs2_inode_lock_full: OCFS2_META_LOCK_GETBH;
it means just getting back disk inode bh for us if we've got cluster lock.
3. export a helper: ocfs2_is_locked_by_me() is used to check if we
have got the cluster lock in the upper code path.

The tracking logic should be used by some of the ocfs2 vfs's callbacks,
to solve the recursive locking issue cuased by the fact that vfs routines
can call into each other.

The performance penalty of processing the holder list should only be seen
at a few cases where the tracking logic is used, such as get/set acl.

You may ask what if the first time we got a PR lock, and the second time
we want a EX lock? fortunately, this case never happens in the real world,
as far as I can see, including permission check, (get|set)_(acl|attr), and
the gfs2 code also do so.

Signed-off-by: Eric Ren 
---
  fs/ocfs2/dlmglue.c | 47 ---
  fs/ocfs2/dlmglue.h | 18 ++
  fs/ocfs2/ocfs2.h   |  1 +
  3 files changed, 63 insertions(+), 3 deletions(-)

diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
index 83d576f..500bda4 100644
--- a/fs/ocfs2/dlmglue.c
+++ b/fs/ocfs2/dlmglue.c
@@ -532,6 +532,7 @@ void ocfs2_lock_res_init_once(struct ocfs2_lock_res *res)
init_waitqueue_head(>l_event);
INIT_LIST_HEAD(>l_blocked_list);
INIT_LIST_HEAD(>l_mask_waiters);
+   INIT_LIST_HEAD(>l_holders);
  }
  
  void ocfs2_inode_lock_res_init(struct ocfs2_lock_res *res,

@@ -749,6 +750,45 @@ void ocfs2_lock_res_free(struct ocfs2_lock_res *res)
res->l_flags = 0UL;
  }
  
+inline void ocfs2_add_holder(struct ocfs2_lock_res *lockres,

+  struct ocfs2_holder *oh)
+{
+   INIT_LIST_HEAD(>oh_list);
+   oh->oh_owner_pid =  get_pid(task_pid(current));
+
+   spin_lock(>l_lock);
+   list_add_tail(>oh_list, >l_holders);
+   spin_unlock(>l_lock);
+}
+
+inline void ocfs2_remove_holder(struct ocfs2_lock_res *lockres,
+  struct ocfs2_holder *oh)
+{
+   spin_lock(>l_lock);
+   list_del(>oh_list);
+   spin_unlock(>l_lock);
+
+   put_pid(oh->oh_owner_pid);
+}
+
+inline struct ocfs2_holder *ocfs2_is_locked_by_me(struct ocfs2_lock_res 
*lockres)
+{
+   struct ocfs2_holder *oh;
+   struct pid *pid;
+
+   /* look in the list of holders for one with the current task as owner */
+   spin_lock(>l_lock);
+   pid = task_pid(current);
+   list_for_each_entry(oh, >l_holders, oh_list) {
+   if (oh->oh_owner_pid == pid)
+   goto out;
+   }
+   oh = NULL;
+out:
+   spin_unlock(>l_lock);
+   return oh;
+}
Since this ocfs2_holder won't be used in the caller, I suggest just 
return a bool value here.

Something like:
spin_lock();
list_for_each_entry() {
if (oh->oh_owner_pid == pid) {
spin_unlock();
return 1;
}
}
spin_unlock();
return 0;

Thanks,
Joseph

+
  static inline void ocfs2_inc_holders(struct ocfs2_lock_res *lockres,
 int level)
  {
@@ -2333,8 +2373,9 @@ int ocfs2_inode_lock_full_nested(struct inode *inode,
goto getbh;
}
  
-	if (ocfs2_mount_local(osb))

-   goto local;
+   if ((arg_flags & OCFS2_META_LOCK_GETBH) ||
+   

[PATCH 1/2] thermal: arm: dra752: Remove TSHUT configuration

[Keerthy]

Technical Reference Manual [1] mandates that software should
not be configuring the thermal shutdown thresholds. Hence
removing TSHUT_CONFIG.

[1] http://www.ti.com/lit/ug/sprui30b/sprui30b.pdf

Signed-off-by: Keerthy 
Reported-by: Ravikumar Kattekola 
---
 drivers/thermal/ti-soc-thermal/dra752-thermal-data.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/thermal/ti-soc-thermal/dra752-thermal-data.c 
b/drivers/thermal/ti-soc-thermal/dra752-thermal-data.c
index 58b5c66..0a3f88d 100644
--- a/drivers/thermal/ti-soc-thermal/dra752-thermal-data.c
+++ b/drivers/thermal/ti-soc-thermal/dra752-thermal-data.c
@@ -416,8 +416,7 @@
 
 /* DRA752 data */
 const struct ti_bandgap_data dra752_data = {
-   .features = TI_BANDGAP_FEATURE_TSHUT_CONFIG |
-   TI_BANDGAP_FEATURE_FREEZE_BIT |
+   .features = TI_BANDGAP_FEATURE_FREEZE_BIT |
TI_BANDGAP_FEATURE_TALERT |
TI_BANDGAP_FEATURE_COUNTER_DELAY |
TI_BANDGAP_FEATURE_HISTORY_BUFFER |
-- 
1.9.1

[PATCH 1/2] thermal: arm: dra752: Remove TSHUT configuration

[Keerthy]

Technical Reference Manual [1] mandates that software should
not be configuring the thermal shutdown thresholds. Hence
removing TSHUT_CONFIG.

[1] http://www.ti.com/lit/ug/sprui30b/sprui30b.pdf

Signed-off-by: Keerthy 
Reported-by: Ravikumar Kattekola 
---
 drivers/thermal/ti-soc-thermal/dra752-thermal-data.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/thermal/ti-soc-thermal/dra752-thermal-data.c 
b/drivers/thermal/ti-soc-thermal/dra752-thermal-data.c
index 58b5c66..0a3f88d 100644
--- a/drivers/thermal/ti-soc-thermal/dra752-thermal-data.c
+++ b/drivers/thermal/ti-soc-thermal/dra752-thermal-data.c
@@ -416,8 +416,7 @@
 
 /* DRA752 data */
 const struct ti_bandgap_data dra752_data = {
-   .features = TI_BANDGAP_FEATURE_TSHUT_CONFIG |
-   TI_BANDGAP_FEATURE_FREEZE_BIT |
+   .features = TI_BANDGAP_FEATURE_FREEZE_BIT |
TI_BANDGAP_FEATURE_TALERT |
TI_BANDGAP_FEATURE_COUNTER_DELAY |
TI_BANDGAP_FEATURE_HISTORY_BUFFER |
-- 
1.9.1

[PATCH 2/2] thermal: arm: dra752: Remove all TSHUT related definitions

[Keerthy]

No configuration needs to be done for TSHUT from software.
Hence remove all the unnecessary definitions.

Signed-off-by: Keerthy 
---
 drivers/thermal/ti-soc-thermal/dra752-bandgap.h| 19 
 .../thermal/ti-soc-thermal/dra752-thermal-data.c   | 25 --
 2 files changed, 44 deletions(-)

diff --git a/drivers/thermal/ti-soc-thermal/dra752-bandgap.h 
b/drivers/thermal/ti-soc-thermal/dra752-bandgap.h
index 6b0f2b1..a31e4b5 100644
--- a/drivers/thermal/ti-soc-thermal/dra752-bandgap.h
+++ b/drivers/thermal/ti-soc-thermal/dra752-bandgap.h
@@ -54,7 +54,6 @@
 #define DRA752_STD_FUSE_OPP_BGAP_CORE_OFFSET   0x8
 #define DRA752_TEMP_SENSOR_CORE_OFFSET 0x154
 #define DRA752_BANDGAP_THRESHOLD_CORE_OFFSET   0x1ac
-#define DRA752_BANDGAP_TSHUT_CORE_OFFSET   0x1b8
 #define DRA752_BANDGAP_CUMUL_DTEMP_CORE_OFFSET 0x1c4
 #define DRA752_DTEMP_CORE_0_OFFSET 0x208
 #define DRA752_DTEMP_CORE_1_OFFSET 0x20c
@@ -66,7 +65,6 @@
 #define DRA752_STD_FUSE_OPP_BGAP_IVA_OFFSET0x388
 #define DRA752_TEMP_SENSOR_IVA_OFFSET  0x398
 #define DRA752_BANDGAP_THRESHOLD_IVA_OFFSET0x3a4
-#define DRA752_BANDGAP_TSHUT_IVA_OFFSET0x3ac
 #define DRA752_BANDGAP_CUMUL_DTEMP_IVA_OFFSET  0x3b4
 #define DRA752_DTEMP_IVA_0_OFFSET  0x3d0
 #define DRA752_DTEMP_IVA_1_OFFSET  0x3d4
@@ -78,7 +76,6 @@
 #define DRA752_STD_FUSE_OPP_BGAP_MPU_OFFSET0x4
 #define DRA752_TEMP_SENSOR_MPU_OFFSET  0x14c
 #define DRA752_BANDGAP_THRESHOLD_MPU_OFFSET0x1a4
-#define DRA752_BANDGAP_TSHUT_MPU_OFFSET0x1b0
 #define DRA752_BANDGAP_CUMUL_DTEMP_MPU_OFFSET  0x1bc
 #define DRA752_DTEMP_MPU_0_OFFSET  0x1e0
 #define DRA752_DTEMP_MPU_1_OFFSET  0x1e4
@@ -90,7 +87,6 @@
 #define DRA752_STD_FUSE_OPP_BGAP_DSPEVE_OFFSET 0x384
 #define DRA752_TEMP_SENSOR_DSPEVE_OFFSET   0x394
 #define DRA752_BANDGAP_THRESHOLD_DSPEVE_OFFSET 0x3a0
-#define DRA752_BANDGAP_TSHUT_DSPEVE_OFFSET 0x3a8
 #define DRA752_BANDGAP_CUMUL_DTEMP_DSPEVE_OFFSET   0x3b0
 #define DRA752_DTEMP_DSPEVE_0_OFFSET   0x3bc
 #define DRA752_DTEMP_DSPEVE_1_OFFSET   0x3c0
@@ -102,7 +98,6 @@
 #define DRA752_STD_FUSE_OPP_BGAP_GPU_OFFSET0x0
 #define DRA752_TEMP_SENSOR_GPU_OFFSET  0x150
 #define DRA752_BANDGAP_THRESHOLD_GPU_OFFSET0x1a8
-#define DRA752_BANDGAP_TSHUT_GPU_OFFSET0x1b4
 #define DRA752_BANDGAP_CUMUL_DTEMP_GPU_OFFSET  0x1c0
 #define DRA752_DTEMP_GPU_0_OFFSET  0x1f4
 #define DRA752_DTEMP_GPU_1_OFFSET  0x1f8
@@ -173,10 +168,6 @@
 #define DRA752_BANDGAP_THRESHOLD_HOT_MASK  (0x3ff << 16)
 #define DRA752_BANDGAP_THRESHOLD_COLD_MASK (0x3ff << 0)
 
-/* DRA752.TSHUT_THRESHOLD */
-#define DRA752_TSHUT_THRESHOLD_MUXCTRL_MASKBIT(31)
-#define DRA752_TSHUT_THRESHOLD_HOT_MASK(0x3ff << 16)
-#define DRA752_TSHUT_THRESHOLD_COLD_MASK   (0x3ff << 0)
 
 /* DRA752.BANDGAP_CUMUL_DTEMP_CORE */
 #define DRA752_BANDGAP_CUMUL_DTEMP_CORE_MASK   (0x << 0)
@@ -216,8 +207,6 @@
 #define DRA752_GPU_MAX_TEMP125000
 #define DRA752_GPU_HYST_VAL5000
 /* interrupts thresholds */
-#define DRA752_GPU_TSHUT_HOT   915
-#define DRA752_GPU_TSHUT_COLD  900
 #define DRA752_GPU_T_HOT   800
 #define DRA752_GPU_T_COLD  795
 
@@ -230,8 +219,6 @@
 #define DRA752_MPU_MAX_TEMP125000
 #define DRA752_MPU_HYST_VAL5000
 /* interrupts thresholds */
-#define DRA752_MPU_TSHUT_HOT   915
-#define DRA752_MPU_TSHUT_COLD  900
 #define DRA752_MPU_T_HOT   800
 #define DRA752_MPU_T_COLD  795
 
@@ -244,8 +231,6 @@
 #define DRA752_CORE_MAX_TEMP   125000
 #define DRA752_CORE_HYST_VAL   5000
 /* interrupts thresholds */
-#define DRA752_CORE_TSHUT_HOT  915
-#define DRA752_CORE_TSHUT_COLD 900
 #define DRA752_CORE_T_HOT  800
 #define DRA752_CORE_T_COLD 795
 
@@ -258,8 +243,6 @@
 #define DRA752_DSPEVE_MAX_TEMP 125000
 #define DRA752_DSPEVE_HYST_VAL 5000
 /* interrupts thresholds */
-#define DRA752_DSPEVE_TSHUT_HOT915
-#define DRA752_DSPEVE_TSHUT_COLD   900
 #define 

[PATCH 2/2] thermal: arm: dra752: Remove all TSHUT related definitions

[Keerthy]

No configuration needs to be done for TSHUT from software.
Hence remove all the unnecessary definitions.

Signed-off-by: Keerthy 
---
 drivers/thermal/ti-soc-thermal/dra752-bandgap.h| 19 
 .../thermal/ti-soc-thermal/dra752-thermal-data.c   | 25 --
 2 files changed, 44 deletions(-)

diff --git a/drivers/thermal/ti-soc-thermal/dra752-bandgap.h 
b/drivers/thermal/ti-soc-thermal/dra752-bandgap.h
index 6b0f2b1..a31e4b5 100644
--- a/drivers/thermal/ti-soc-thermal/dra752-bandgap.h
+++ b/drivers/thermal/ti-soc-thermal/dra752-bandgap.h
@@ -54,7 +54,6 @@
 #define DRA752_STD_FUSE_OPP_BGAP_CORE_OFFSET   0x8
 #define DRA752_TEMP_SENSOR_CORE_OFFSET 0x154
 #define DRA752_BANDGAP_THRESHOLD_CORE_OFFSET   0x1ac
-#define DRA752_BANDGAP_TSHUT_CORE_OFFSET   0x1b8
 #define DRA752_BANDGAP_CUMUL_DTEMP_CORE_OFFSET 0x1c4
 #define DRA752_DTEMP_CORE_0_OFFSET 0x208
 #define DRA752_DTEMP_CORE_1_OFFSET 0x20c
@@ -66,7 +65,6 @@
 #define DRA752_STD_FUSE_OPP_BGAP_IVA_OFFSET0x388
 #define DRA752_TEMP_SENSOR_IVA_OFFSET  0x398
 #define DRA752_BANDGAP_THRESHOLD_IVA_OFFSET0x3a4
-#define DRA752_BANDGAP_TSHUT_IVA_OFFSET0x3ac
 #define DRA752_BANDGAP_CUMUL_DTEMP_IVA_OFFSET  0x3b4
 #define DRA752_DTEMP_IVA_0_OFFSET  0x3d0
 #define DRA752_DTEMP_IVA_1_OFFSET  0x3d4
@@ -78,7 +76,6 @@
 #define DRA752_STD_FUSE_OPP_BGAP_MPU_OFFSET0x4
 #define DRA752_TEMP_SENSOR_MPU_OFFSET  0x14c
 #define DRA752_BANDGAP_THRESHOLD_MPU_OFFSET0x1a4
-#define DRA752_BANDGAP_TSHUT_MPU_OFFSET0x1b0
 #define DRA752_BANDGAP_CUMUL_DTEMP_MPU_OFFSET  0x1bc
 #define DRA752_DTEMP_MPU_0_OFFSET  0x1e0
 #define DRA752_DTEMP_MPU_1_OFFSET  0x1e4
@@ -90,7 +87,6 @@
 #define DRA752_STD_FUSE_OPP_BGAP_DSPEVE_OFFSET 0x384
 #define DRA752_TEMP_SENSOR_DSPEVE_OFFSET   0x394
 #define DRA752_BANDGAP_THRESHOLD_DSPEVE_OFFSET 0x3a0
-#define DRA752_BANDGAP_TSHUT_DSPEVE_OFFSET 0x3a8
 #define DRA752_BANDGAP_CUMUL_DTEMP_DSPEVE_OFFSET   0x3b0
 #define DRA752_DTEMP_DSPEVE_0_OFFSET   0x3bc
 #define DRA752_DTEMP_DSPEVE_1_OFFSET   0x3c0
@@ -102,7 +98,6 @@
 #define DRA752_STD_FUSE_OPP_BGAP_GPU_OFFSET0x0
 #define DRA752_TEMP_SENSOR_GPU_OFFSET  0x150
 #define DRA752_BANDGAP_THRESHOLD_GPU_OFFSET0x1a8
-#define DRA752_BANDGAP_TSHUT_GPU_OFFSET0x1b4
 #define DRA752_BANDGAP_CUMUL_DTEMP_GPU_OFFSET  0x1c0
 #define DRA752_DTEMP_GPU_0_OFFSET  0x1f4
 #define DRA752_DTEMP_GPU_1_OFFSET  0x1f8
@@ -173,10 +168,6 @@
 #define DRA752_BANDGAP_THRESHOLD_HOT_MASK  (0x3ff << 16)
 #define DRA752_BANDGAP_THRESHOLD_COLD_MASK (0x3ff << 0)
 
-/* DRA752.TSHUT_THRESHOLD */
-#define DRA752_TSHUT_THRESHOLD_MUXCTRL_MASKBIT(31)
-#define DRA752_TSHUT_THRESHOLD_HOT_MASK(0x3ff << 16)
-#define DRA752_TSHUT_THRESHOLD_COLD_MASK   (0x3ff << 0)
 
 /* DRA752.BANDGAP_CUMUL_DTEMP_CORE */
 #define DRA752_BANDGAP_CUMUL_DTEMP_CORE_MASK   (0x << 0)
@@ -216,8 +207,6 @@
 #define DRA752_GPU_MAX_TEMP125000
 #define DRA752_GPU_HYST_VAL5000
 /* interrupts thresholds */
-#define DRA752_GPU_TSHUT_HOT   915
-#define DRA752_GPU_TSHUT_COLD  900
 #define DRA752_GPU_T_HOT   800
 #define DRA752_GPU_T_COLD  795
 
@@ -230,8 +219,6 @@
 #define DRA752_MPU_MAX_TEMP125000
 #define DRA752_MPU_HYST_VAL5000
 /* interrupts thresholds */
-#define DRA752_MPU_TSHUT_HOT   915
-#define DRA752_MPU_TSHUT_COLD  900
 #define DRA752_MPU_T_HOT   800
 #define DRA752_MPU_T_COLD  795
 
@@ -244,8 +231,6 @@
 #define DRA752_CORE_MAX_TEMP   125000
 #define DRA752_CORE_HYST_VAL   5000
 /* interrupts thresholds */
-#define DRA752_CORE_TSHUT_HOT  915
-#define DRA752_CORE_TSHUT_COLD 900
 #define DRA752_CORE_T_HOT  800
 #define DRA752_CORE_T_COLD 795
 
@@ -258,8 +243,6 @@
 #define DRA752_DSPEVE_MAX_TEMP 125000
 #define DRA752_DSPEVE_HYST_VAL 5000
 /* interrupts thresholds */
-#define DRA752_DSPEVE_TSHUT_HOT915
-#define DRA752_DSPEVE_TSHUT_COLD   900
 #define 

[PATCH 0/2] thermal: omap: dra752: Remove TSHUT configuration

[Keerthy]

Technical Reference Manual [1] mandates that software should
not be configuring the thermal shutdown thresholds. Hence
removing TSHUT_CONFIG.

[1] http://www.ti.com/lit/ug/sprui30b/sprui30b.pdf

Keerthy (2):
  thermal: omap: dra752: Remove TSHUT configuration
  thermal: omap: dra752: Remove all TSHUT related definitions

 drivers/thermal/ti-soc-thermal/dra752-bandgap.h| 19 ---
 .../thermal/ti-soc-thermal/dra752-thermal-data.c   | 28 +-
 2 files changed, 1 insertion(+), 46 deletions(-)

-- 
1.9.1

[PATCH 0/2] thermal: omap: dra752: Remove TSHUT configuration

[Keerthy]

Technical Reference Manual [1] mandates that software should
not be configuring the thermal shutdown thresholds. Hence
removing TSHUT_CONFIG.

[1] http://www.ti.com/lit/ug/sprui30b/sprui30b.pdf

Keerthy (2):
  thermal: omap: dra752: Remove TSHUT configuration
  thermal: omap: dra752: Remove all TSHUT related definitions

 drivers/thermal/ti-soc-thermal/dra752-bandgap.h| 19 ---
 .../thermal/ti-soc-thermal/dra752-thermal-data.c   | 28 +-
 2 files changed, 1 insertion(+), 46 deletions(-)

-- 
1.9.1

RE: [PATCH v4 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma

[Appana Durga Kedareswara Rao]

Hi Rob,

Thanks for the review...

 [Snip]
> > -- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> >> > +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> >> > @@ -66,6 +66,8 @@ Optional child node properties:
> >> >  Optional child node properties for VDMA:
> >> >  - xlnx,genlock-mode: Tells Genlock synchronization is
> >> > enabled/disabled in hardware.
> >> > +- xlnx,fstore-config: Tells Whether Frame Store Configuration is
> >> > +   enabled/disabled in hardware.
> >>
> >> What's the default (when not present)? That should be the most common
> case.
> >> Looks like the code treats this as bool, but that's not clear here.
> >> The name is not clear what it is doing. Enabling or disabling the feature?
> >
> > Default value is zero...
> > When this property is present it tells hardware is configured for frame 
> > store
> configuration.
> 
> So most people will not want "frame store configuration"?

Since the driver is for SoftIP (I mean fpga ip) default h/w configuration of 
this IP is frame store
Configuration disabled that's in the driver making default value of this 
configuration as zero.

If users are trying a use case where this configuration should be enabled but 
in the h/w it is disabled.
In this case driver will warn users to enable this frame store configuration in 
the h/w.
So that users can enable it in their h/w.

Please let me know if the above expiation is not clear will explain in detail...

> 
> > Will fix the explanation part in the next version like below.
> >  xlnx,fstore-config: Tells hardware is configured for frame store 
> > configuration.
> > Is the above explanation clear???
> 
> No, I mean make it obvious from the name of the property:
> xlnx,fstore-config-enable or xlnx,fstore-enable
> 
> And the description needs to say it is boolean.

Sure will fix in the next version...

Regards,
Kedar.

> 
> Rob

RE: [PATCH v4 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma

[Appana Durga Kedareswara Rao]

Hi Rob,

Thanks for the review...

 [Snip]
> > -- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> >> > +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> >> > @@ -66,6 +66,8 @@ Optional child node properties:
> >> >  Optional child node properties for VDMA:
> >> >  - xlnx,genlock-mode: Tells Genlock synchronization is
> >> > enabled/disabled in hardware.
> >> > +- xlnx,fstore-config: Tells Whether Frame Store Configuration is
> >> > +   enabled/disabled in hardware.
> >>
> >> What's the default (when not present)? That should be the most common
> case.
> >> Looks like the code treats this as bool, but that's not clear here.
> >> The name is not clear what it is doing. Enabling or disabling the feature?
> >
> > Default value is zero...
> > When this property is present it tells hardware is configured for frame 
> > store
> configuration.
> 
> So most people will not want "frame store configuration"?

Since the driver is for SoftIP (I mean fpga ip) default h/w configuration of 
this IP is frame store
Configuration disabled that's in the driver making default value of this 
configuration as zero.

If users are trying a use case where this configuration should be enabled but 
in the h/w it is disabled.
In this case driver will warn users to enable this frame store configuration in 
the h/w.
So that users can enable it in their h/w.

Please let me know if the above expiation is not clear will explain in detail...

> 
> > Will fix the explanation part in the next version like below.
> >  xlnx,fstore-config: Tells hardware is configured for frame store 
> > configuration.
> > Is the above explanation clear???
> 
> No, I mean make it obvious from the name of the property:
> xlnx,fstore-config-enable or xlnx,fstore-enable
> 
> And the description needs to say it is boolean.

Sure will fix in the next version...

Regards,
Kedar.

> 
> Rob

Re: [PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 01월 06일 14:22에 Andi Shyti 이(가) 쓴 글:
> Hi Hoegeun,
> 
>> +static const struct drm_display_mode default_mode = {
>> +.clock = 222372,
>> +.hdisplay = 1440,
>> +.hsync_start = 1440 + 1,
>> +.hsync_end = 1440 + 1 + 1,
>> +.htotal = 1440 + 1 + 1 + 1,
>> +.vdisplay = 2560,
>> +.vsync_start = 2560 + 1,
>> +.vsync_end = 2560 + 1 + 1,
>> +.vtotal = 2560 + 1 + 1 + 15,
>> +.vrefresh = 60,
>> +.flags = 0,
>> +};
> 
> how is this working with tm2e? Are these values valid for both
> the boards?

We don't need to consider tm2e board with two reasones,
1. there is no tm2e board support in mainline
2. the panel on tm2 would be a little bit different from one on tm2e

Thanks,
Inki Dae

> 
> Andi
> 
> 

Re: [PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 01월 06일 14:22에 Andi Shyti 이(가) 쓴 글:
> Hi Hoegeun,
> 
>> +static const struct drm_display_mode default_mode = {
>> +.clock = 222372,
>> +.hdisplay = 1440,
>> +.hsync_start = 1440 + 1,
>> +.hsync_end = 1440 + 1 + 1,
>> +.htotal = 1440 + 1 + 1 + 1,
>> +.vdisplay = 2560,
>> +.vsync_start = 2560 + 1,
>> +.vsync_end = 2560 + 1 + 1,
>> +.vtotal = 2560 + 1 + 1 + 15,
>> +.vrefresh = 60,
>> +.flags = 0,
>> +};
> 
> how is this working with tm2e? Are these values valid for both
> the boards?

We don't need to consider tm2e board with two reasones,
1. there is no tm2e board support in mainline
2. the panel on tm2 would be a little bit different from one on tm2e

Thanks,
Inki Dae

> 
> Andi
> 
> 

Re: [PATCH net-next v4 0/4] Fix OdroidC2 Gigabit Tx link issue

[Yegor Yefremov]

Hi Russel,

On Fri, Jan 6, 2017 at 12:25 AM, Russell King - ARM Linux
 wrote:
> On Mon, Nov 28, 2016 at 09:54:28AM -0800, Florian Fainelli wrote:
>> If we start supporting generic "enable", "disable" type of properties
>> with values that map directly to register definitions of the HW, we
>> leave too much room for these properties to be utilized to implement a
>> specific policy, and this is not acceptable.
>
> Another concern with this patch is that the existing phylib "set_eee"
> code is horribly buggy - it just translates the modes from userspace
> into the register value and writes them directly to the register with
> no validation.  So it's possible to set modes in the register that the
> hardware doesn't support, and have them advertised to the link partner.
>
> I have a patch which fixes that, restricting (as we do elsewhere) the
> advert according to the EEE supported capabilities retrieved from the
> PCS - maybe the problem here is that the PCS doesn't support support
> EEE in 1000baseT mode?
>
> Out of interest, which PHY is used on this platform?
>
> On the SolidRun boards, they're using AR8035, and have suffered this
> occasional link drop problem.  What has been found is that it seems to
> be to do with the timing parameters, and it seemed to only be 1000bT
> that was affected.  I don't remember off hand exactly which or what
> the change was they made to stabilise it though, but I can probabily
> find out tomorrow.

I have different boards with am335x and AR8035 and we had occasional
link drop with both 100 and 1000 speeds.

Yegor

Re: [PATCH net-next v4 0/4] Fix OdroidC2 Gigabit Tx link issue

[Yegor Yefremov]

Hi Russel,

On Fri, Jan 6, 2017 at 12:25 AM, Russell King - ARM Linux
 wrote:
> On Mon, Nov 28, 2016 at 09:54:28AM -0800, Florian Fainelli wrote:
>> If we start supporting generic "enable", "disable" type of properties
>> with values that map directly to register definitions of the HW, we
>> leave too much room for these properties to be utilized to implement a
>> specific policy, and this is not acceptable.
>
> Another concern with this patch is that the existing phylib "set_eee"
> code is horribly buggy - it just translates the modes from userspace
> into the register value and writes them directly to the register with
> no validation.  So it's possible to set modes in the register that the
> hardware doesn't support, and have them advertised to the link partner.
>
> I have a patch which fixes that, restricting (as we do elsewhere) the
> advert according to the EEE supported capabilities retrieved from the
> PCS - maybe the problem here is that the PCS doesn't support support
> EEE in 1000baseT mode?
>
> Out of interest, which PHY is used on this platform?
>
> On the SolidRun boards, they're using AR8035, and have suffered this
> occasional link drop problem.  What has been found is that it seems to
> be to do with the timing parameters, and it seemed to only be 1000bT
> that was affected.  I don't remember off hand exactly which or what
> the change was they made to stabilise it though, but I can probabily
> find out tomorrow.

I have different boards with am335x and AR8035 and we had occasional
link drop with both 100 and 1000 speeds.

Yegor

[PATCH 2/2] cpufreq: Documentation: Updates based on current code

[Viresh Kumar]

The cpufreq core has gone though lots of updates in recent times, but on
many occasions the documentation wasn't updated along with the code.
This patch tries to catchup the documentation with the code.

Also add Rafael and Viresh as the contributors to the documentation.

Based on a patch from Claudio Scordino.

Signed-off-by: Claudio Scordino 
Signed-off-by: Viresh Kumar 
---
 Documentation/cpu-freq/core.txt  |  24 +++--
 Documentation/cpu-freq/cpu-drivers.txt   | 177 +--
 Documentation/cpu-freq/cpufreq-stats.txt |  24 ++---
 Documentation/cpu-freq/governors.txt | 117 +++-
 Documentation/cpu-freq/index.txt |  23 ++--
 Documentation/cpu-freq/user-guide.txt|  60 ++-
 6 files changed, 232 insertions(+), 193 deletions(-)

diff --git a/Documentation/cpu-freq/core.txt b/Documentation/cpu-freq/core.txt
index 4bc7287806de..978463a7c81e 100644
--- a/Documentation/cpu-freq/core.txt
+++ b/Documentation/cpu-freq/core.txt
@@ -8,6 +8,8 @@
 
Dominik Brodowski  
 David Kimdon 
+   Rafael J. Wysocki 
+  Viresh Kumar 
 
 
 
@@ -36,10 +38,11 @@ speed limits (like LCD drivers on ARM architecture). 
Additionally, the
 kernel "constant" loops_per_jiffy is updated on frequency changes
 here.
 
-Reference counting is done by cpufreq_get_cpu and cpufreq_put_cpu,
-which make sure that the cpufreq processor driver is correctly
-registered with the core, and will not be unloaded until
-cpufreq_put_cpu is called.
+Reference counting of the cpufreq policies is done by cpufreq_cpu_get
+and cpufreq_cpu_put, which make sure that the cpufreq driver is
+correctly registered with the core, and will not be unloaded until
+cpufreq_put_cpu is called. That also ensures that the respective cpufreq
+policy doesn't get freed while being used.
 
 2. CPUFreq notifiers
 
@@ -69,18 +72,16 @@ These are notified when a new policy is intended to be set. 
Each
 The phase is specified in the second argument to the notifier.
 
 The third argument, a void *pointer, points to a struct cpufreq_policy
-consisting of five values: cpu, min, max, policy and max_cpu_freq. min 
-and max are the lower and upper frequencies (in kHz) of the new
-policy, policy the new policy, cpu the number of the affected CPU; and 
-max_cpu_freq the maximum supported CPU frequency. This value is given 
-for informational purposes only.
+consisting of several values, including min, max (the lower and upper
+frequencies (in kHz) of the new policy).
 
 
 2.2 CPUFreq transition notifiers
 
 
-These are notified twice when the CPUfreq driver switches the CPU core
-frequency and this change has any external implications.
+These are notified twice for each online CPU in the policy, when the
+CPUfreq driver switches the CPU core frequency and this change has no
+any external implications.
 
 The second argument specifies the phase - CPUFREQ_PRECHANGE or
 CPUFREQ_POSTCHANGE.
@@ -90,6 +91,7 @@ The third argument is a struct cpufreq_freqs with the 
following
 cpu- number of the affected CPU
 old- old frequency
 new- new frequency
+flags  - flags of the cpufreq driver
 
 3. CPUFreq Table Generation with Operating Performance Point (OPP)
 ==
diff --git a/Documentation/cpu-freq/cpu-drivers.txt 
b/Documentation/cpu-freq/cpu-drivers.txt
index 772b94fde264..f71e6be26b83 100644
--- a/Documentation/cpu-freq/cpu-drivers.txt
+++ b/Documentation/cpu-freq/cpu-drivers.txt
@@ -9,6 +9,8 @@
 
 
Dominik Brodowski  
+   Rafael J. Wysocki 
+  Viresh Kumar 
 
 
 
@@ -49,49 +51,65 @@ using cpufreq_register_driver()
 
 What shall this struct cpufreq_driver contain? 
 
-cpufreq_driver.name -  The name of this driver.
+ .name - The name of this driver.
 
-cpufreq_driver.init -  A pointer to the per-CPU initialization 
-   function.
+ .init - A pointer to the per-policy initialization function.
 
-cpufreq_driver.verify -A pointer to a "verification" function.
+ .verify - A pointer to a "verification" function.
 
-cpufreq_driver.setpolicy _or_ 
-cpufreq_driver.target/
-target_index   -   See below on the differences.
+ .setpolicy _or_ .fast_switch _or_ .target _or_ .target_index - See
+ below on the differences.
 
 And optionally
 
-cpufreq_driver.exit -  A pointer to a per-CPU cleanup
-   function called during CPU_POST_DEAD
-   phase of cpu hotplug process.
+ .flags - Hints for the cpufreq core.
 
-cpufreq_driver.stop_cpu -  A pointer to a per-CPU stop function

[PATCH 2/2] cpufreq: Documentation: Updates based on current code

[Viresh Kumar]

The cpufreq core has gone though lots of updates in recent times, but on
many occasions the documentation wasn't updated along with the code.
This patch tries to catchup the documentation with the code.

Also add Rafael and Viresh as the contributors to the documentation.

Based on a patch from Claudio Scordino.

Signed-off-by: Claudio Scordino 
Signed-off-by: Viresh Kumar 
---
 Documentation/cpu-freq/core.txt  |  24 +++--
 Documentation/cpu-freq/cpu-drivers.txt   | 177 +--
 Documentation/cpu-freq/cpufreq-stats.txt |  24 ++---
 Documentation/cpu-freq/governors.txt | 117 +++-
 Documentation/cpu-freq/index.txt |  23 ++--
 Documentation/cpu-freq/user-guide.txt|  60 ++-
 6 files changed, 232 insertions(+), 193 deletions(-)

diff --git a/Documentation/cpu-freq/core.txt b/Documentation/cpu-freq/core.txt
index 4bc7287806de..978463a7c81e 100644
--- a/Documentation/cpu-freq/core.txt
+++ b/Documentation/cpu-freq/core.txt
@@ -8,6 +8,8 @@
 
Dominik Brodowski  
 David Kimdon 
+   Rafael J. Wysocki 
+  Viresh Kumar 
 
 
 
@@ -36,10 +38,11 @@ speed limits (like LCD drivers on ARM architecture). 
Additionally, the
 kernel "constant" loops_per_jiffy is updated on frequency changes
 here.
 
-Reference counting is done by cpufreq_get_cpu and cpufreq_put_cpu,
-which make sure that the cpufreq processor driver is correctly
-registered with the core, and will not be unloaded until
-cpufreq_put_cpu is called.
+Reference counting of the cpufreq policies is done by cpufreq_cpu_get
+and cpufreq_cpu_put, which make sure that the cpufreq driver is
+correctly registered with the core, and will not be unloaded until
+cpufreq_put_cpu is called. That also ensures that the respective cpufreq
+policy doesn't get freed while being used.
 
 2. CPUFreq notifiers
 
@@ -69,18 +72,16 @@ These are notified when a new policy is intended to be set. 
Each
 The phase is specified in the second argument to the notifier.
 
 The third argument, a void *pointer, points to a struct cpufreq_policy
-consisting of five values: cpu, min, max, policy and max_cpu_freq. min 
-and max are the lower and upper frequencies (in kHz) of the new
-policy, policy the new policy, cpu the number of the affected CPU; and 
-max_cpu_freq the maximum supported CPU frequency. This value is given 
-for informational purposes only.
+consisting of several values, including min, max (the lower and upper
+frequencies (in kHz) of the new policy).
 
 
 2.2 CPUFreq transition notifiers
 
 
-These are notified twice when the CPUfreq driver switches the CPU core
-frequency and this change has any external implications.
+These are notified twice for each online CPU in the policy, when the
+CPUfreq driver switches the CPU core frequency and this change has no
+any external implications.
 
 The second argument specifies the phase - CPUFREQ_PRECHANGE or
 CPUFREQ_POSTCHANGE.
@@ -90,6 +91,7 @@ The third argument is a struct cpufreq_freqs with the 
following
 cpu- number of the affected CPU
 old- old frequency
 new- new frequency
+flags  - flags of the cpufreq driver
 
 3. CPUFreq Table Generation with Operating Performance Point (OPP)
 ==
diff --git a/Documentation/cpu-freq/cpu-drivers.txt 
b/Documentation/cpu-freq/cpu-drivers.txt
index 772b94fde264..f71e6be26b83 100644
--- a/Documentation/cpu-freq/cpu-drivers.txt
+++ b/Documentation/cpu-freq/cpu-drivers.txt
@@ -9,6 +9,8 @@
 
 
Dominik Brodowski  
+   Rafael J. Wysocki 
+  Viresh Kumar 
 
 
 
@@ -49,49 +51,65 @@ using cpufreq_register_driver()
 
 What shall this struct cpufreq_driver contain? 
 
-cpufreq_driver.name -  The name of this driver.
+ .name - The name of this driver.
 
-cpufreq_driver.init -  A pointer to the per-CPU initialization 
-   function.
+ .init - A pointer to the per-policy initialization function.
 
-cpufreq_driver.verify -A pointer to a "verification" function.
+ .verify - A pointer to a "verification" function.
 
-cpufreq_driver.setpolicy _or_ 
-cpufreq_driver.target/
-target_index   -   See below on the differences.
+ .setpolicy _or_ .fast_switch _or_ .target _or_ .target_index - See
+ below on the differences.
 
 And optionally
 
-cpufreq_driver.exit -  A pointer to a per-CPU cleanup
-   function called during CPU_POST_DEAD
-   phase of cpu hotplug process.
+ .flags - Hints for the cpufreq core.
 
-cpufreq_driver.stop_cpu -  A pointer to a per-CPU stop function
-   called during CPU_DOWN_PREPARE phase of
-   cpu hotplug process.
+ .driver_data - cpufreq driver specific data.
 
-cpufreq_driver.resume -