mmotm 2010-04-05-16-09 uploaded
Subsystems (5)
The mm-of-the-moment snapshot 2010-04-05-16-09 has been uploaded to
http://userweb.kernel.org/~akpm/mmotm/
and will soon be available at
git://zen-kernel.org/kernel/mmotm.git
It contains the following patches against 2.6.34-rc3:
origin.patch
rmap-fix-anon_vma_fork-memory-leak.patch
bitops-remove-temporary-for_each_bit.patch
linux-next.patch
linux-next-git-rejects.patch
next-remove-localversion.patch
i-need-old-gcc.patch
arch-x86-crypto-aesni-intel_asms-still-busted.patch include-linux-fsh-complete-hexification-of-fmode_-constants.patch
exit-fix-oops-in-sync_mm_rss.patch
exit-fix-oops-in-sync_mm_rss-fix.patch
include-linux-kfifoh-fix-init_kfifo.patch vesafb-use-platform_driver_probe-instead-of-platform_driver_register.patch fbdev-rename-imacfbtxt-to-efifbtxt-and-change-imacfb-to-efifb.patch drivers-char-amiserialc-add-missing-local_irq_restore.patch drivers-gpio-timbgpioc-add-missing-unlock.patch
omap-hsmmc-fix-a-bug-in-card-remove-scenario.patch initramfs-prevent-buffer-overflow-when-unpacking-to-rootfs.patch
mxser-spin_lock-=-spin_lock_irq.patch
mxser-spin_lock-=-spin_lock_irq-fix.patch
cciss-unlock-on-error-path.patch drivers-thermal-thermal_sysc-fix-key-f70f4b50-not-in-data-in-thermal_sys.patch device_attributes-add-sysfs_attr_init-for-dynamic-attributes.patch readahead-fix-null-filp-dereference.patch
devmem-handle-class_create-failure.patch
mm-revert-vmscan-get_scan_ratio-cleanup.patch
mb862xxfb-fix-acceleration-module-license.patch
mb862xxfb-update-valentins-email-address.patch
raw-fsync-method-is-now-required.patch
bsdacct-use-del_timer_sync-in-acct_exit_ns.patch
fbdev-fix-kconfig-breakage-in-drivers-video.patch
ratelimit-annotate-___ratelimit.patch
ratelimit-annotate-___ratelimit-fix.patch
kernelh-fix-wrong-usage-of-__ratelimit.patch ratelimit-fix-the-return-value-when-__ratelimit-fails-to-acquire-the-lock.patch pagemap-fix-pfn-calculation-for-hugepage-v3.patch
memcg-fix-race-in-file_mapped-accounting.patch
rtc-mxc-multiple-fixes-in-rtc-mxc-probe-method.patch rtc-mxc-multiple-fixes-in-rtc-mxc-probe-method-checkpatch-fixes.patch frv-hide-uncached_access-when-pgprot_noncached-is-not-defined.patch frv-fix-kernel-user-segment-handling-in-nommu-mode.patch frv-extend-gdbstub-to-support-more-features-of-gdb.patch frv-extend-gdbstub-to-support-more-features-of-gdb-fix.patch fs-cache-order-the-debugfs-stats-correctly.patch
it8761e_gpio-fix-bug-in-gpio-numbering.patch power_meter-acpi_device_class-power_meter_resource-too-long.patch block-elevatorc-fix-block-elevatorc-elevator_get-off-by-one-error.patch drivers-base-cpuc-fix-the-output-from-sys-devices-system-cpu-offline.patch intel-agpc-fix-crash-when-accessing-nonexistent-gtt-entries-in-i915.patch intel-agpc-fix-crash-when-accessing-nonexistent-gtt-entries-in-i915-checkpatch-fixes.patch inotify-dont-leak-user-struct-on-inotify-release.patch
oprofile-remove-double-ring-buffering.patch
arch-powerpc-kernel-vioc-add-missing-unlock.patch
drivers-macintosh-macio-adbc-add-missing-unlock.patch sched-prevent-compiler-from-optimising-sched_avg_update-loop.patch dpt_i20-several-use-after-free-issues.patch
scsi-be2iscsi-fix-lock-imbalance.patch
scsi-lpfc-fix-lock-imbalances.patch
scsi-qla2xxx-fix-lock-imbalance.patch
drivers-scsi-qla2xxx-qla_attrc-add-missing-unlock.patch keys-dont-need-to-use-rcu-in-keyring_read-as-semaphore-is-held.patch drivers-serial-pmac_zilogc-add-missing-unlock.patch drivers-usb-gadget-s3c-hsotgc-add-missing-unlock.patch
x86-handle-overlapping-mptables.patch
acerhdf-add-new-bios-versions.patch
drivers-acpi-use-kasprintf.patch
drivers-acpi-use-kasprintf-fix.patch
sbshc-acpi_device_class-smbus_host_controller-too-long.patch acpi_pad-processor_aggregator-name-too-long.patch
acpi-map-pxms-to-low-node-ids.patch
arch-x86-kernel-hpetc-fix-bug-in-rtc-emulation.patch x86-apic-ack-all-pending-irqs-when-crashed-on-kexec-v5.patch
arch-x86-pci-use-kasprintf.patch
x86-nosmp-command-line-option-should-force-the-system-into-up-mode.patch arch-x86-kernel-setupcl-phoenix-bios-fixup-is-needed-on-dell-inspiron-mini-1012.patch agp-amd64-fix-pci-reference-leaks.patch
arm-convert-proc-cpu-aligment-to-seq_file.patch
arch-arm-plat-pxa-dmac-correct-null-test.patch arch-arm-include-asm-elfh-forward-declare-the-task-struct.patch cifs-provide-user-with-a-hint-when-name-resolution-fails.patch cifs-provide-user-with-a-hint-when-name-resolution-fails-fix.patch dmaengine-support-for-st-ericssons-dma40-block-v3.patch dmaengine-dma40-u8500-platform-configuration-v3.patch powerpc-sky-cpu-redundant-or-incorrect-tests-on-unsigned.patch arch-powerpc-platforms-pseries-use-kasprintf.patch
gpu-vga_switcheroo-fix-lock-imbalance.patch
drivers-gpu-drm-via-via_videoc-fix-off-by-one-issue.patch drivers-gpu-drm-radeon-radeon_atombiosc-range-check-issues.patch drivers-gpu-drm-drm_sysfsc-sysfs-files-error-handling.patch drivers-gpu-drm-drm_memoryc-fix-check-for-end-of-loop.patch
dib3000mc-reduce-large-stack-usage.patch
dib7000p-reduce-large-stack-usage.patch
dvb-usb-gp8psk-fix-potential-null-derefernce.patch
drivers-media-video-avoid-null-dereference.patch drivers-media-video-au0828-au0828-videoc-off-by-one-bug.patch drivers-media-video-zc0301-zc0301_corec-improve-error-handling.patch drivers-media-video-et61x251-et61x251_corec-improve-error-handling.patch drivers-media-video-sn9c102-sn9c102_corec-improve-error-handling.patch
cx88-improve-error-handling.patch
ir-keytable-avoid-double-lock.patch
fs-fscache-object-listc-fix-warning-on-32-bit.patch
intel-iommu-use-for_each_set_bit.patch
gpiolib-introduce-chip-addition-removal-notifier.patch of-gpio-add-support-for-two-stage-registration-for-the-of_gpio_chips.patch of-gpio-implement-gpiolib-notifier-hooks.patch
of-gpio-implement-gpiolib-notifier-hooks-fix.patch of-gpio-implement-gpiolib-notifier-hooks-fix-fix2.patch powerpc-mcu_mpc8349emitx-remove-of-gpio-handling-stuff.patch gpiolib-cosmetic-improvements-for-error-handling-in-gpiochip_add.patch timers-introduce-the-concept-of-timer-slack-for-legacy-timers.patch cpu-timers-simplify-rlimit_cpu-handling.patch
cpu-timers-cleanup-arm_timer.patch
cpu-timers-return-correct-previous-timer-reload-value.patch cpu-timers-change-sigev_none-timer-implementation.patch cpu-timers-assure-to-not-iterate-over-all-threads-in-fastpath_timer_check.patch cpu-timers-optimize-run_posix_cpu_timers.patch
cs5535-clockevt-free-timer-in-irq-setup-error-path.patch timer-print-function-name-for-timer-callbacks-modifying-preemption-count.patch time-clean-up-warp_clock.patch
time-clean-up-direct-xtime-usage-in-xen.patch
ntp-make-time_adjust-static.patch
ntp-remove-tickadj.patch
ati_remote-add-some-missing-devices-from-lirc_atiusb.patch usbtouchscreen-support-bigger-inexio-touchscreens.patch matrix_keypad-allow-platform-to-disable-key-autorepeat.patch
markup_oops-fix-perlcritic-warnings.patch
led-driver-for-the-soekris-net5501-board.patch led-driver-for-the-soekris-net5501-board-checkpatch-fixes.patch led-driver-for-the-soekris-net5501-board-fix-2.patch leds-route-kbd-leds-through-the-generic-leds-layer.patch leds-route-kbd-leds-through-the-generic-leds-layer-leds-input-depends-on-input.patch leds-route-kbd-leds-through-the-generic-leds-layer-fix.patch drivers-mfd-pcf50633-corec-off-by-one-issue.patch mfd-add-support-for-janz-cmod-io-pci-modulbus-carrier-board.patch can-add-support-for-janz-vmod-ican3-intelligent-can-module.patch gpio-add-support-for-janz-vmod-ttl-digital-io-module.patch gpio-add-support-for-janz-vmod-ttl-digital-io-module-fix.patch hrtimer-provide-schedule_hrtimeout-for-wallclock.patch ipc-mqueuec-let-message-queue-timeout-use-hrtimers.patch ipc-mqueuec-let-message-queue-timeout-use-hrtimers-checkpatch-fixes.patch bitops-rename-for_each_bit-to-for_each_set_bit-mtd.patch mtd-nandsim-fix-typo-struct-nandsin_geometry.patch mtd-nand-remove-stray-endchoice-from-kconfig-help-text.patch ntfs-clean-up-ntfs_attr_extend_initialized.patch
ntfs-use-add_to_page_cache_lru.patch
score-fix-dereference-of-null-pointer-in-local_flush_tlb_page.patch x25-attempts-to-negotiate-invalid-throughput.patch
3x59x-fix-pci-resource-management.patch mbp_nvidia_bl-add-support-for-older-macbookpro-and-macbook-61.patch backlight-backlight_device_register-return-err_ptr.patch backlight-add-s6e63m0-amoled-lcd-panel-driver.patch backlight-add-s6e63m0-amoled-lcd-panel-driver-checkpatch-fixes.patch sunrpc-use-formatting-of-module-name-in-sunrpc.patch serial-two-branches-the-same-in-timbuart_set_mctrl.patch serial-timbuart-make-sure-last-byte-is-sent-when-port-is-closed.patch serial-timbuart-make-sure-last-byte-is-sent-when-port-is-closed-fix.patch serial-8250_pnp-add-fujitsu-wacom-device.patch
kernel-irq-managec-add-raise_threaded_irq.patch
kernel-irq-managec-add-raise_threaded_irq-fix.patch
max3100-move-to-threaded-interrupt.patch
max3100-add-console-support-for-max3100.patch
max3100-to_max3100_port-small-style-fixes.patch
max3100-to_max3100_port-small-style-fixes-fix.patch
serial-add-driver-for-the-altera-jtag-uart.patch
serial-add-driver-for-the-altera-uart.patch
serial-add-driver-for-the-altera-uart-update.patch
s390-potential-buffer-overflow.patch
kernel-irq-procc-expose-the-irq_desc-node-in-proc-irq.patch lockdep-add-novalidate-class-for-dev-mutex-conversion.patch rcu-remove-init_rcu_head-rcu_head_init-rcu_head.patch
scsi-add-__init-__exit-macros-to-ibmvstgtc.patch
drivers-scsi-fnic-fnic_scsic-clean-up.patch
drivers-scsi-gdthc-fix-buffer-overflow.patch
drivers-scsi-lpfc-lpfc_vportc-fix-read-buffer-overflow.patch
osst-fix-read-buffer-overflow.patch gdth-unmap-ccb_phys-when-scsi_add_host-fails-in-gdth_eisa_probe_one.patch drivers-scsi-libsas-use-sam_good.patch
ncr5380-bit-mr_dma_mode-set-twice-in-ncr5380_transfer_dma.patch drivers-scsi-remove-unnecessary-null-test.patch
drivers-message-move-dereference-after-null-test.patch scsi-pmcraid-redundant-check-in-pmcraid_check_ioctl_buffer.patch
mpt-fusion-convert-to-seq_file.patch
g_ncr5380-remove-misleading-pnp-error-message.patch
g_ncr5380-fix-broken-mmio-compilation.patch g_ncr5380-fix-missing-pnp_device_detach-and-scsi_unregister-on-rmmod.patch dc395x-decrease-iteration-for-tag_number-of-max_command-in-start_scsi.patch drivers-scsi-correct-the-size-argument-to-kmalloc.patch scsi-remove-superfluous-null-pointer-check-from-scsi_kill_request.patch mpt2sas-fix-confusion-in-_scsih_sas_device_status_change_event.patch scsi-sdc-quiet-all-sparse-noise.patch
drivers-scsi-bfa-bfad_imc-eliminate-useless-code.patch
lpfc-positive-error-return-into-negative.patch drivers-scsi-qla2xxx-qla_osc-fix-continuation-line-formats.patch scsi-bfa-correct-onstack-wait_queue_head-declaration.patch mptscsih-fix-first-line-of-kernel-doc-for-a-few-functions.patch drivers-scsi-chc-dont-use-vprintk-as-macro.patch
iscsi-change-to.patch
scsi-fix-convert-scsi_scanc-kernel-doc.patch
scsi-update-drivers-tools-url-references.patch bfa-wrong-fcport-h2i-message-tested-in-bfa_fcport_isr.patch wd7000-typo-spin_unlock_irq-=-spin_lock_irq.patch
fs-splicec-fix-mapping_gfp_mask-usage.patch iio-iio_get_new_idr_val-return-negative-value-on-failure.patch iio-iio_get_new_idr_val-return-negative-value-on-failure-fix.patch vt6655-cgi-csi-confusion-in-device_ioctl.patch drivers-staging-otus-hal-hpanic-using-the-wrong-variable.patch drivers-staging-comedi-drivers-dt2801c-off-by-one-issue.patch
musb-potential-use-after-free.patch
kaweth-new-usb-id-07c9-b010-allied-telesyn-at-usb10.patch usb-fix-serial-build-when-sysrq-is-disabled.patch
usb-oxu210hp-release-spinlock-on-error-path.patch
9p-return-on-mutex_lock_interruptible.patch
9p-saving-negative-to-unsigned-char.patch vfs-fix-vfs_rename_dir-for-fs_rename_does_d_move-filesystems.patch vfs-improve-comment-describing-fget_light.patch
ecryptfs-another-lockdep-issue.patch
vfs-o_-bit-numbers-uniqueness-check.patch
vfs-o_-bit-numbers-uniqueness-check-update.patch
vfs-o_-bit-numbers-uniqueness-check-fix.patch
vfs-o_-bit-numbers-uniqueness-check-fix-2.patch vfs-introduce-fmode_neg_offset-for-allowing-negative-f_pos.patch vfs-clarify-that-nonseekable_open-will-never-fail.patch watchdog-docs-fix-use-of-wdioc_setoptions-ioctl.patch
xtensa-convert-to-asm-generic-hardirqh.patch
xtensa-includecheck-fix-vectorss.patch
xtensa-fix-unnecessary-setting-of-xtime.patch
modpost-support-objects-with-more-than-64k-sections.patch
mm.patch page-allocator-reduce-fragmentation-in-buddy-allocator-by-adding-buddies-that-are-merging-to-the-tail-of-the-free-lists.patch sparsemem-on-no-vmemmap-path-put-mem_map-on-node-high-too.patch
shmem-remove-redundant-code.patch
define-madv_hugepage.patch
mm-remove-return-value-of-putback_lru_pages.patch
mempolicy-remove-redundant-code.patch
oom-filter-tasks-not-sharing-the-same-cpuset.patch oom-sacrifice-child-with-highest-badness-score-for-parent.patch oom-select-task-from-tasklist-for-mempolicy-ooms.patch oom-remove-special-handling-for-pagefault-ooms.patch
oom-badness-heuristic-rewrite.patch
oom-deprecate-oom_adj-tunable.patch
oom-replace-sysctls-with-quick-mode.patch
oom-avoid-oom-killer-for-lowmem-allocations.patch
oom-remove-unnecessary-code-and-cleanup.patch
oom-default-to-killing-current-for-pagefault-ooms.patch oom-avoid-race-for-oom-killed-tasks-detaching-mm-prior-to-exit.patch oom-select_bad_process-check-pf_kthread-instead-of-mm-to-skip-kthreads.patch oom-select_bad_process-pf_exiting-check-should-take-mm-into-account.patch oom-introduce-find_lock_task_mm-to-fix-mm-false-positives.patch oom-oom_forkbomb_penalty-move-thread_group_cputime-out-of-task_lock.patch oom-hold-tasklist_lock-when-dumping-tasks.patch oom-give-current-access-to-memory-reserves-if-it-has-been-killed.patch oom-avoid-sending-exiting-tasks-a-sigkill.patch
oom-clean-up-oom_kill_task.patch
oom-clean-up-oom_badness.patch
mempolicy-remove-case-mpol_interleave-from-policy_zonelist.patch
mempolicy-remove-redundant-check.patch
mempolicy-dont-call-mpol_set_nodemask-when-no_context.patch mempolicy-lose-unnecessary-loop-variable-in-mpol_parse_str.patch mempolicy-rename-policy_types-and-cleanup-initialization.patch mempolicy-factor-mpol_shared_policy_init-return-paths.patch mempolicy-document-cpuset-interaction-with-tmpfs-mpol-mount-option.patch
mincore-cleanups.patch
mincore-break-do_mincore-into-logical-pieces.patch
mincore-pass-ranges-as-startend-address-pairs.patch
mincore-do-nested-page-table-walks.patch pagemap-add-ifdefs-config_hugetlb_page-on-code-walking-hugetlb-vma.patch mm-default-to-node-zonelist-ordering-when-nodes-have-only-lowmem.patch oom-move-sysctl-declarations-to-oomh.patch
fs-writebackc-bitfields-should-be-unsigned.patch
frv-duplicate-output_buffer-of-e03.patch
frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch nommu-allow-private-mappings-of-read-only-devices.patch errh-add-__must_check-to-error-pointer-handlers.patch
kernel-user-remove-unreachable-code.patch
endian-define-__byte_order.patch
bitops-optimize-hweight-by-making-use-of-compile-time-evaluation.patch x86-add-optimized-popcnt-variants.patch
hangcheck-timer-fix-x86_32-bugs.patch
improve-sys_personality-for-compat-architectures.patch
vsprintfc-use-noinline_for_stack.patch
dynamic_debug-small-cleanup-in-ddebug_proc_write.patch lib-hexdumpc-reduce-stack-variable-size-and-cleanups.patch firmware-loader-use-statically-initialized-data-attribute.patch firmware-loader-use-statically-initialized-data-attribute-fix.patch firmware-loader-use-statically-initialized-data-attribute-fix-fix.patch davinci-mmc-pass-number-of-sg-segments-as-platform-data.patch mmc-omap-add-support-for-16-bit-and-32-bit-registers.patch sdhci-implement-cap_clock_base_broken-quirk.patch
sdhci-pltfm-implement-platform-data-passing.patch sdhci-pltfm-do-not-print-errors-in-case-of-an-extended-iomem-size.patch davinci-mmc-add-a-function-to-control-reset-state-of-the-controller.patch davinci-mmc-updates-to-suspend-resume-implementation.patch davinci-mmc-updates-to-suspend-resume-implementation-checkpatch-fixes.patch checkpatch-add-check-for-too-short-kconfig-descriptions.patch checkpatch-add-check-for-too-short-kconfig-descriptions-checkpatch-fixes.patch hwmon-driver-for-ti-tmp102-temperature-sensor.patch hwmon-driver-for-ti-tmp102-temperature-sensor-fix.patch
xen-fix-build-when-sysrq-is-disabled.patch
s3c-rtc-driver-add-support-for-s3c64xx.patch rtc-mxc-remove-unnecessary-clock-source-for-rtc-subsystem.patch gpio-add-interrupt-handling-capability-to-max732x.patch gpiolib-make-names-array-and-its-values-const.patch gpiolib-make-names-array-and-its-values-const-fix.patch gpiolib-a-gpio-is-unsigned-so-use-%u-to-print-it.patch gpiolib-document-that-names-can-contain-printk-format-specifiers.patch fbdev-bfin-lq035q1-fb-respect-new-ppi-mode-platform-field.patch
sis-strcpy-=-strlcpy.patch
fbdev-section-cleanup-in-arcfb.patch
fbdev-section-cleanup-in-hgafb.patch
fbdev-section-cleanup-in-vfb.patch
fbdev-section-cleanup-in-vga16fb.patch
fbdev-section-cleanup-in-w100fb.patch
cobalt_lcdfb-fix-section-mismatch-cobalt_lcdfb_fix.patch auxdisplay-section-cleanup-in-cfag12864bfb-driver.patch ext3-fixup-rb_root-initializations-to-use-rb_root.patch hfsplus-identify-journal-info-block-in-volume-header.patch
hfsplus-fix-journal-detection.patch
memcg-oom-wakeup-filter.patch
memcg-oom-wakeup-filter-update.patch
memcg-oom-notifier.patch
memcg-oom-notifier-update.patch
memcg-oom-kill-disable-and-oom-status.patch
memcg-oom-kill-disable-and-oom-status-update.patch memcg-oom-kill-disable-and-oom-status-update-checkpatch-fixes.patch kmod-add-init-function-to-usermodehelper.patch exec-replace-call_usermodehelper_pipe-with-use-of-umh-init-function-and-resolve-limit.patch umh-creds-convert-call_usermodehelper_keys-to-use-subprocess_info-init.patch umh-creds-kill-subprocess_info-cred-logic.patch
call_usermodehelper-no-need-to-unblock-signals.patch wait_for_helper-sigchld-from-user-space-can-lead-to-use-after-free.patch call_usermodehelper-simplify-fix-umh_no_wait-case.patch call_usermodehelper-umh_wait_exec-ignores-kernel_thread-failure.patch coredump-factor-out-the-not-ispipe-file-checks.patch
coredump-cleanup-ispipe-code.patch
coredump-factor-out-put_cred-calls.patch
coredump-shift-down_writemmap_sem-into-coredump_wait.patch exit-exit_notify-can-trust-signal-notify_count-0.patch exit-change-zap_other_threads-to-count-sub-threads.patch exit-avoid-sig-count-in-de_thread-__exit_signal-synchronization.patch exit-avoid-sig-count-in-__exit_signal-to-detect-the-group-dead-case.patch posix-cpu-timers-avoid-task-signal-=-null-checks.patch ia64-ptrace_attach_sync_user_rbs-avoid-task-signal-=-null-checks.patch fork-exit-move-tty_kref_put-outside-of-__cleanup_signal.patch signals-make-task_struct-signal-immutable-refcountable.patch signals-clear-signal-tty-when-the-last-thread-exits.patch signals-clear-signal-tty-when-the-last-thread-exits-fix.patch signals-kill-the-awful-task_rq_unlock_wait-hack.patch exit-__exit_signal-use-thread_group_leader-consistently.patch kill-the-obsolete-thread_group_cputime_free-and-taskstats_tgid_init-helpers.patch exit-move-taskstats_tgid_free-from-__exit_signal-to-free_signal_struct.patch check_unshare_flags-kill-the-bogus-clone_sighand-sig-count-check.patch proc-get_nr_threads-doesnt-need-siglock-any-longer.patch
proc-make-collect_sigign_sigcatch-rcu-safe.patch
proc-make-task_sig-lockless.patch
proc_sched_show_task-use-get_nr_threads.patch keyctl_session_to_parent-use-thread_group_empty-to-check-singlethreadness.patch proc-turn-signal_struct-count-into-int-nr_threads.patch proc-turn-signal_struct-count-into-int-nr_threads-checkpatch-fixes.patch proc-cleanup-remove-unused-assignments.patch cpu-hotplug-introduce-cpu_notify-__cpu_notify-cpu_notify_nofail.patch cpu-hotplug-return-better-errno-on-cpu-hotplug-failure.patch notifier-change-notifier_from_errno0-to-return-notify_ok.patch x86-convert-cpu-notifier-to-return-encapsulate-errno-value.patch topology-convert-cpu-notifier-to-return-encapsulate-errno-value.patch kernel-convert-cpu-notifier-to-return-encapsulate-errno-value.patch slab-convert-cpu-notifier-to-return-encapsulate-errno-value.patch iucv-convert-cpu-notifier-to-return-encapsulate-errno-value.patch ehca-convert-cpu-notifier-to-return-encapsulate-errno-value.patch s390-convert-cpu-notifier-to-return-encapsulate-errno-value.patch md-convert-cpu-notifier-to-return-encapsulate-errno-value.patch fault-injection-add-cpu-notifier-error-injection-module.patch fault-injection-add-cpu-notifier-error-injection-module-fix.patch cpuhotplug-do-not-need-cpu_hotplug_begin-when-config_hotplug_cpu=n.patch ipmi-raise-precedence-of-pnp-based-discovery-mechanisms-acpi-pci.patch ipmi-convert-tracking-of-the-acpi-device-pointer-to-a-pnp-device.patch ipmi-update-driver-to-use-dev_printk-and-its-constructs.patch
char-drivers-ram-oops-panic-logger.patch
char-drivers-ram-oops-panic-logger-update.patch
drivers-char-ppdevc-use-kasprintf.patch delay-accounting-re-implement-c-for-getdelaysc-to-report-information-on-a-target-command.patch delay-accounting-re-implement-c-for-getdelaysc-to-report-information-on-a-target-command-checkpatch-fixes.patch delayacct-align-to-8-byte-boundary-on-64-bit-systems.patch lib-random32-export-pseudo-random-number-generator-for-modules.patch drivers-edac-introduce-missing-kfree.patch
edac-add-__init-to-i7core_xeon_pci_fixup.patch
ssb-add-dma_dev-to-ssb_device-structure.patch b43legacy-replace-the-ssb_dma-api-with-the-generic-dma-api.patch b43-replace-the-ssb_dma-api-with-the-generic-dma-api.patch b44-replace-the-ssb_dma-api-with-the-generic-dma-api.patch
ssb-remove-the-ssb-dma-api.patch
panic-allow-taint-flag-for-warnings-to-be-changed-from-taint_warn.patch panic-allow-taint-flag-for-warnings-to-be-changed-from-taint_warn-checkpatch-fixes.patch panic-add-taint-flag-taint_firmware_workaround-i.patch pci-dmar-combine-the-bios-dmar-table-warning-messages.patch pci-dmar-tone-down-warnings-about-invalid-bios-dmar-tables.patch kfifo-kfifo_is_fullempty-should-return-bools-not-ints.patch
time-kill-off-config_generic_time.patch
asm-generic-remove-isa_dma_threshold-in-scatterlisth.patch asm-generic-add-need_sg_dma_length-to-define-sg_dma_len.patch asm-generic-add-need_sg_dma_length-to-define-sg_dma_len-fix.patch powerpc-use-asm-generic-scatterlisth.patch
arm-use-asm-generic-scatterlisth.patch
alpha-use-asm-generic-scatterlisth.patch
vfs-add-super-operation-writeback_inodes.patch
vfs-take-2add-set_page_dirty_notag.patch
reiser4-export-remove_from_page_cache.patch
reiser4-export-remove_from_page_cache-fix.patch
reiser4-export-find_get_pages.patch
reiser4.patch
reiser4-writeback_inodes-implementation.patch
reiser4-writeback_inodes-implementation-fix.patch
reiser4-fixup-checkin-checkout-jnodes-for-entd.patch
reiser4-fixups.patch
reiser4-broke.patch
make-sure-nobodys-leaking-resources.patch
journal_add_journal_head-debug.patch
releasing-resources-with-children.patch
make-frame_pointer-default=y.patch
mutex-subsystem-synchro-test-module.patch mutex-subsystem-synchro-test-module-add-missing-header-file.patch
slab-leaks3-default-y.patch
put_bh-debug.patch
add-debugging-aid-for-memory-initialisation-problems.patch
workaround-for-a-pci-restoring-bug.patch
prio_tree-debugging-patch.patch
single_open-seq_release-leak-diagnostics.patch
add-a-refcount-check-in-dput.patch
getblk-handle-2tb-devices.patch
getblk-handle-2tb-devices-fix.patch
notify_change-callers-must-hold-i_mutex.patch
PATCH 1/1 hid-picolcd: depends on LCD_CLASS_DEVICE
From: Randy Dunlap <[email protected]>
HID_PICOLCD should depend on LCD_CLASS_DEVICE, otherwise the build fails when HID_PICOLCD=y and LCD_CLASS_DEVICE=m:
hid-picolcd.c:(.text+0x84523f): undefined reference to lcd_device_unregister' hid-picolcd.c:(.text+0x8478ab): undefined reference to lcd_device_register' hid-picolcd.c:(.text+0x84c15f): undefined reference to `lcd_device_unregister'
--- drivers/hid/Kconfig | 1 + 1 file changed, 1 insertion(+)
drivers/hid/Kconfig +1 -0
@@ -265,6 +265,7 @@ config HID_PETALYNX config HID_PICOLCD tristate "PicoLCD (graphic version)" depends on USB_HID + depends on LCD_CLASS_DEVICE select FB_DEFERRED_IO if FB select FB_SYS_FILLRECT if FB select FB_SYS_COPYAREA if FB
Re: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE
[ adding Bruno to CC ]
Quoted 17 lines · Randy Dunlap
From: Randy Dunlap <[email protected]>
HID_PICOLCDshould depend onLCD_CLASS_DEVICE, otherwise the build fails when HID_PICOLCD=y and LCD_CLASS_DEVICE=m:hid-picolcd.c:(.text+0x84523f): undefined reference to
lcd_device_unregister' hid-picolcd.c:(.text+0x8478ab): undefined reference tolcd_device_register' hid-picolcd.c:(.text+0x84c15f): undefined reference to `lcd_device_unregister'Signed-off-by Randy Dunlap <[email protected]>--- drivers/hid/Kconfig | 1 + 1 file changed, 1 insertion(+)
drivers/hid/Kconfig config HID_PETALYNX · line 271
Quoted 7 lines
drivers/hid/Kconfig +1
-0@@ -265,6 +265,7 @@ config HID_PETALYNX config HID_PICOLCD tristate "PicoLCD (graphic version)" depends on USB_HID + depends on LCD_CLASS_DEVICE select FB_DEFERRED_IO if FB select FB_SYS_FILLRECT if FB select FB_SYS_COPYAREA if FB
Thanks Randy. We'll have to take care of the other dependencies as well though (CONFIG_LCD_CLASS_DEVICE, CONFIG_LEDS_CLASS).
Signature · 2 lines
Jiri Kosina SUSE Labs, Novell Inc.
Bruno Prémont
maintainerRe: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE
Quoted 13 lines · On Tue, 6 Apr 2010 10:40:06 +0200 Jiri Kosina <[email protected]> wrote:
[ adding Bruno to CC ]
Quoted 8 lines · Randy Dunlap
From: Randy Dunlap <[email protected]>
HID_PICOLCDshould depend onLCD_CLASS_DEVICE, otherwise the build fails when HID_PICOLCD=y and LCD_CLASS_DEVICE=m:hid-picolcd.c:(.text+0x84523f): undefined reference to
lcd_device_unregister' hid-picolcd.c:(.text+0x8478ab): undefined reference tolcd_device_register' hid-picolcd.c:(.text+0x84c15f): undefined reference to `lcd_device_unregister'
That is weird, the
#if defined(CONFIG_LCD_CLASS_DEVICE) || defined(CONFIG_LCD_CLASS_DEVICE_MODULE)
feature support code
#else
empty stubs
#endif
blocks should have prevented LCD_CLASS support from being built if it was not enabled in configuration.
Do you have the .config matching your build?
When I did my test-build with LCD support enabled/disabled I didn't get any linker errors as those mentioned above.
Thanks,
Bruno
Quoted 19 lines
Quoted 8 lines
Signed-off-by Randy Dunlap <[email protected]>--- drivers/hid/Kconfig | 1 + 1 file changed, 1 insertion(+)drivers/hid/Kconfig config HID_PETALYNX · line 271
Quoted 7 lines
drivers/hid/Kconfig +1
-0@@ -265,6 +265,7 @@ config HID_PETALYNX config HID_PICOLCD tristate "PicoLCD (graphic version)" depends on USB_HID + depends on LCD_CLASS_DEVICE select FB_DEFERRED_IO if FB select FB_SYS_FILLRECT if FB select FB_SYS_COPYAREA if FBThanks Randy. We'll have to take care of the other dependencies as well though (
CONFIG_LCD_CLASS_DEVICE,CONFIG_LEDS_CLASS).
Re: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE
Quoted 23 lines · On Tue, 6 Apr 2010 10:56:35 +0200 Bruno Prémont wrote:
Quoted 13 lines · On Tue, 6 Apr 2010 10:40:06 +0200 Jiri Kosina <[email protected]> wrote:
[ adding Bruno to CC ]
Quoted 8 lines · Randy Dunlap
From: Randy Dunlap <[email protected]>
HID_PICOLCDshould depend onLCD_CLASS_DEVICE, otherwise the build fails when HID_PICOLCD=y and LCD_CLASS_DEVICE=m:hid-picolcd.c:(.text+0x84523f): undefined reference to
lcd_device_unregister' hid-picolcd.c:(.text+0x8478ab): undefined reference tolcd_device_register' hid-picolcd.c:(.text+0x84c15f): undefined reference to `lcd_device_unregister'That is weird, the
#if
defined(CONFIG_LCD_CLASS_DEVICE)||defined(CONFIG_LCD_CLASS_DEVICE_MODULE)
feature support code
#else
empty stubs
#endif
Quoted 4 lines
blocks should have prevented
LCD_CLASSsupport from being built if it was not enabled in configuration.Do you have the .config matching your build?
Yes, it's attached.
Quoted 26 lines
When I did my test-build with LCD support enabled/disabled I didn't get any linker errors as those mentioned above.
Thanks,
BrunoQuoted 5 lines
Quoted 5 lines
Signed-off-by Randy Dunlap <[email protected]>--- drivers/hid/Kconfig | 1 + 1 file changed, 1 insertion(+)Quoted 13 lines
drivers/hid/Kconfig config HID_PETALYNX · line 271
Quoted 10 lines
drivers/hid/Kconfig +1
-0@@ -265,6 +265,7 @@ config HID_PETALYNX config HID_PICOLCD tristate "PicoLCD (graphic version)" depends on USB_HID + depends on LCD_CLASS_DEVICE select FB_DEFERRED_IO if FB select FB_SYS_FILLRECT if FB select FB_SYS_COPYAREA if FBThanks Randy. We'll have to take care of the other dependencies as well though (
CONFIG_LCD_CLASS_DEVICE,CONFIG_LEDS_CLASS).
Quoted 1 line
--
---
~Randy
(re)read Documentation/ManagementStyle
Bruno Prémont
maintainerRe: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE
Quoted 25 lines · On Tue, 06 April 2010 Randy Dunlap <[email protected]> wrote:
Quoted 23 lines · On Tue, 6 Apr 2010 10:56:35 +0200 Bruno Prémont wrote:
Quoted 13 lines · On Tue, 6 Apr 2010 10:40:06 +0200 Jiri Kosina <[email protected]> wrote:
[ adding Bruno to CC ]
Quoted 8 lines · Randy Dunlap
From: Randy Dunlap <[email protected]>
HID_PICOLCDshould depend onLCD_CLASS_DEVICE, otherwise the build fails when HID_PICOLCD=y and LCD_CLASS_DEVICE=m:hid-picolcd.c:(.text+0x84523f): undefined reference to
lcd_device_unregister' hid-picolcd.c:(.text+0x8478ab): undefined reference tolcd_device_register' hid-picolcd.c:(.text+0x84c15f): undefined reference to `lcd_device_unregister'That is weird, the
#if
defined(CONFIG_LCD_CLASS_DEVICE)||defined(CONFIG_LCD_CLASS_DEVICE_MODULE)
feature support code
#else
empty stubs
#endif
Quoted 6 lines
Quoted 4 lines
blocks should have prevented
LCD_CLASSsupport from being built if it was not enabled in configuration.Do you have the .config matching your build?
Yes, it's attached.
Thanks, here is the extract (only the pertinent items):CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=m CONFIG_BACKLIGHT_CLASS_DEVICE=y CONFIG_HID_PICOLCD=y
It triggers the issue by having PicoLCD built-in while one of the optional dependencies as a module.
Any idea of how this can be solved with kbuild in order to keep the dependencies optional?
Something that would satisfy the following pseudocode:
if CONFIG_HID_PICOLCD == y
assert(CONFIG_LCD_CLASS_DEVICE != m)
One of my attempts did end up with a circular loop with regard to FB (some of the FB drivers did select INPUT)?
I had something like:
config HID_PICOLCD
tristate ...
config HID_PICOLCD_FB
bool ...
depends on HID_PICOLCD
select FB
select FB_...
...
Then in the code I checked for CONFIG_HID_PICOLCD_FB instead of (CONFIG_FB or CONFIG_FB_MODULE).
Thanks,
Bruno
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE
Quoted 33 lines · On Tue, 6 Apr 2010 18:35:35 +0200 Bruno Prémont wrote:
Quoted 25 lines · On Tue, 06 April 2010 Randy Dunlap <[email protected]> wrote:
Quoted 23 lines · On Tue, 6 Apr 2010 10:56:35 +0200 Bruno Prémont wrote:
Quoted 13 lines · On Tue, 6 Apr 2010 10:40:06 +0200 Jiri Kosina <[email protected]> wrote:
[ adding Bruno to CC ]
Quoted 8 lines · Randy Dunlap
From: Randy Dunlap <[email protected]>
HID_PICOLCDshould depend onLCD_CLASS_DEVICE, otherwise the build fails when HID_PICOLCD=y and LCD_CLASS_DEVICE=m:hid-picolcd.c:(.text+0x84523f): undefined reference to
lcd_device_unregister' hid-picolcd.c:(.text+0x8478ab): undefined reference tolcd_device_register' hid-picolcd.c:(.text+0x84c15f): undefined reference to `lcd_device_unregister'That is weird, the
#if
defined(CONFIG_LCD_CLASS_DEVICE)||defined(CONFIG_LCD_CLASS_DEVICE_MODULE)
feature support code
#else
empty stubs
#endifQuoted 6 lines
Quoted 4 lines
blocks should have prevented
LCD_CLASSsupport from being built if it was not enabled in configuration.Do you have the .config matching your build?
Yes, it's attached.
Quoted 8 lines
Thanks, here is the extract (only the pertinent items):
CONFIG_BACKLIGHT_LCD_SUPPORT=yCONFIG_LCD_CLASS_DEVICE=mCONFIG_BACKLIGHT_CLASS_DEVICE=yCONFIG_HID_PICOLCD=yIt triggers the issue by having PicoLCD built-in while one of the optional dependencies as a module.
Yes, basically what the patch description said.
Quoted 7 lines
Any idea of how this can be solved with kbuild in order to keep the dependencies optional?
Something that would satisfy the following pseudocode:
ifCONFIG_HID_PICOLCD== yassert(CONFIG_LCD_CLASS_DEVICE != m)
If you don't want the kconfig machinery to do that (it appears that you don't), then I guess that you'll need to expand the source code to handle CONFIG_LCD_CLASS_DEVICE=y and CONFIG_LCD_CLASS_DEVICE=m differently. Or only handle them differently if HID_PICOLCD=y. :(
Quoted 3 lines
One of my attempts did end up with a circular loop with regard to FB (some of the FB drivers did select INPUT)?
(not that I can find)
CONFIG_VT does select INPUT
and CONFIG_DRM_I915 does
select INPUT if ACPI
Quoted 11 lines
I had something like:
config
HID_PICOLCD
tristate ...config
HID_PICOLCD_FB
bool ...
depends onHID_PICOLCD
select FB
selectFB_...
Quoted 4 lines
...
Then in the code I checked for
CONFIG_HID_PICOLCD_FBinstead of (CONFIG_FBorCONFIG_FB_MODULE).
---
~Randy
(re)read Documentation/ManagementStyle
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Bruno Prémont
maintainerRe: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE
Quoted 4 lines · On Tue, 06 April 2010 Randy Dunlap <[email protected]> wrote:
Quoted 2 lines
It triggers the issue by having PicoLCD built-in while one of the optional dependencies as a module.
Yes, basically what the patch description said.
Oops, sorry I didn't completely read the patch description.
Quoted 8 lines
Quoted 7 lines
Any idea of how this can be solved with kbuild in order to keep the dependencies optional?
Something that would satisfy the following pseudocode:
ifCONFIG_HID_PICOLCD== yassert(CONFIG_LCD_CLASS_DEVICE != m)
Quoted 4 lines
If you don't want the kconfig machinery to do that (it appears that you don't), then I guess that you'll need to expand the source code to handle
CONFIG_LCD_CLASS_DEVICE=yandCONFIG_LCD_CLASS_DEVICE=mdifferently. Or only handle them differently if HID_PICOLCD=y. :(
Below a patch (against 2.6.34-rc3 + Jiri's picolcd branch) which should fix above issue keeping the deps optional.
With it it's not yet possible to select the deps from HID menu.
I did a few oldconfig and compile-tests with PICOLCD=y/m and same for the deps (not switched FB for those tests).
Bruno
HID_PICOLCD should depend on LCD_CLASS_DEVICE, otherwise the build fails when HID_PICOLCD=y and LCD_CLASS_DEVICE=m:
hid-picolcd.c:(.text+0x84523f): undefined reference to lcd_device_unregister' hid-picolcd.c:(.text+0x8478ab): undefined reference to lcd_device_register' hid-picolcd.c:(.text+0x84c15f): undefined reference to `lcd_device_unregister'
drivers/hid/Kconfig +29 -0
@@ -285,6 +285,35 @@ config HID_PICOLCD Features that are not (yet) supported: - IR +config HID_PICOLCD_FB + bool "Framebuffer support" + default !EMBEDDED + depends on HID_PICOLCD + depends on HID_PICOLCD=FB || FB=y + select FB_DEFERRED_IO + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + +config HID_PICOLCD_BACKLIGHT + bool "Backlight control" + default !EMBEDDED + depends on HID_PICOLCD + depends on HID_PICOLCD=BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=y + +config HID_PICOLCD_LCD + bool "Contrast control" + default !EMBEDDED + depends on HID_PICOLCD + depends on HID_PICOLCD=LCD_CLASS_DEVICE || LCD_CLASS_DEVICE=y + +config HID_PICOLCD_LEDS + bool "GPO via leds class" + default !EMBEDDED + depends on HID_PICOLCD + depends on HID_PICOLCD=LEDS_CLASS || LEDS_CLASS=y + config HID_QUANTA tristate "Quanta Optical Touch" depends on USB_HID
drivers/hid/hid-picolcd.c +20 -20
@@ -77,7 +77,7 @@#define REPORT_HOOK_VERSION 0xf7/* LCD: IN[2], OUT[1] */ #define REPORT_EXIT_FLASHER 0xff/* Bootloader: OUT[2] */ -#if defined(CONFIG_FB ) || defined(CONFIG_FB_MODULE ) +#ifdef CONFIG_HID_PICOLCD_FB /* Framebuffer * * The PicoLCD use a Topway LCD module of 256x64 pixel
@@ -128,7 +128,7 @@ static const struct fb_var_screeninfo picolcdfb_var = { .bits_per_pixel = 1, .grayscale = 1, }; -#endif /* CONFIG_FB */ +#endif /* CONFIG_HID_PICOLCD_FB */ /* Input device *
@@ -183,7 +183,7 @@ struct picolcd_data {struct input_dev *input_cir;unsigned short keycode[PICOLCD_KEYS ]; -#if defined(CONFIG_FB ) || defined(CONFIG_FB_MODULE ) +#ifdef CONFIG_HID_PICOLCD_FB /* Framebuffer stuff */ u8 fb_update_rate;u8 fb_bpp;
@@ -191,21 +191,21 @@ struct picolcd_data {u8 *fb_bitmap;/* framebuffer */ struct fb_info *fb_info;struct fb_deferred_io fb_defio; -#endif /* CONFIG_FB */ -#if defined(CONFIG_LCD_CLASS_DEVICE ) || defined(CONFIG_LCD_CLASS_DEVICE_MODULE ) +#endif /* CONFIG_HID_PICOLCD_FB */ +#ifdef CONFIG_HID_PICOLCD_LCD struct lcd_device *lcd;u8 lcd_contrast; -#endif -#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE ) || defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE ) +#endif /* CONFIG_HID_PICOLCD_LCD */ +#ifdef CONFIG_HID_PICOLCD_BACKLIGHT struct backlight_device *backlight;u8 lcd_brightness;u8 lcd_power; -#endif /* CONFIG_BACKLIGHT_CLASS_DEVICE */ -#if defined(CONFIG_LEDS_CLASS ) || defined(CONFIG_LEDS_CLASS_MODULE ) +#endif /* CONFIG_HID_PICOLCD_BACKLIGHT */ +#ifdef CONFIG_HID_PICOLCD_LEDS /* LED stuff */ u8 led_state;struct led_classdev *led[8 ]; -#endif /* CONFIG_LEDS_CLASS */ +#endif /* CONFIG_HID_PICOLCD_LEDS */ /* Housekeeping stuff */ spinlock_t lock;
@@ -287,7 +287,7 @@ static struct picolcd_pending *picolcd_send_and_wait(struct hid_device *hdev,return work; } -#if defined(CONFIG_FB ) || defined(CONFIG_FB_MODULE ) +#ifdef CONFIG_HID_PICOLCD_FB /* Send a given tile to PicoLCD */ static int picolcd_fb_send_tile (struct hid_device *hdev,int chip,int tile) {
@@ -766,9 +766,9 @@ static void picolcd_exit_framebuffer(struct picolcd_data *data) { }#define picolcd_fbinfo (d) NULL -#endif /* CONFIG_FB */ +#endif /* CONFIG_HID_PICOLCD_FB */ -#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE ) || defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE ) +#ifdef CONFIG_HID_PICOLCD_BACKLIGHT /* * backlight class device */
@@ -864,9 +864,9 @@ static inline int picolcd_resume_backlight(struct picolcd_data *data) {return 0 ; } -#endif /* CONFIG_BACKLIGHT_CLASS_DEVICE */ +#endif /* CONFIG_HID_PICOLCD_BACKLIGHT */ -#if defined(CONFIG_LCD_CLASS_DEVICE ) || defined(CONFIG_LCD_CLASS_DEVICE_MODULE ) +#ifdef CONFIG_HID_PICOLCD_LCD /* * lcd class device */
@@ -957,9 +957,9 @@ static inline int picolcd_resume_lcd(struct picolcd_data *data) {return 0 ; } -#endif /* CONFIG_LCD_CLASS_DEVICE */ +#endif /* CONFIG_HID_PICOLCD_LCD */ -#if defined(CONFIG_LEDS_CLASS ) || defined(CONFIG_LEDS_CLASS_MODULE ) +#ifdef CONFIG_HID_PICOLCD_LEDS /** * LED class device */
@@ -1104,7 +1104,7 @@ static inline int picolcd_leds_set(struct picolcd_data *data) {return 0 ; } -#endif /* CONFIG_LEDS_CLASS */ +#endif /* CONFIG_HID_PICOLCD_LEDS */ /* * input class device
@@ -1243,10 +1243,10 @@ static int picolcd_reset(struct hid_device *hdev)picolcd_resume_lcd (data);picolcd_resume_backlight (data); -#if defined(CONFIG_FB ) || defined(CONFIG_FB_MODULE ) +#ifdef CONFIG_HID_PICOLCD_FB if (data->fb_info)schedule_delayed_work (&data->fb_info->deferred_work,0 ); -#endif /* CONFIG_FB */ +#endif /* CONFIG_HID_PICOLCD_FB */ picolcd_leds_set (data);return 0 ;
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE
Quoted 50 lines · On Tue, 6 Apr 2010 23:04:34 +0200 Bruno Prémont wrote:
Quoted 4 lines · On Tue, 06 April 2010 Randy Dunlap <[email protected]> wrote:
Quoted 2 lines
It triggers the issue by having PicoLCD built-in while one of the optional dependencies as a module.
Yes, basically what the patch description said.
Oops, sorry I didn't completely read the patch description.
Quoted 8 lines
Quoted 7 lines
Any idea of how this can be solved with kbuild in order to keep the dependencies optional?
Something that would satisfy the following pseudocode:
ifCONFIG_HID_PICOLCD== yassert(CONFIG_LCD_CLASS_DEVICE != m)Quoted 4 lines
If you don't want the kconfig machinery to do that (it appears that you don't), then I guess that you'll need to expand the source code to handle
CONFIG_LCD_CLASS_DEVICE=yandCONFIG_LCD_CLASS_DEVICE=mdifferently. Or only handle them differently if HID_PICOLCD=y. :(Below a patch (against 2.6.34-rc3 + Jiri's picolcd branch) which should fix above issue keeping the deps optional.
With it it's not yet possible to select the deps from HID menu.
I did a few oldconfig and compile-tests with PICOLCD=y/m and same for the deps (not switched FB for those tests).
Bruno
HID_PICOLCDshould depend onLCD_CLASS_DEVICE, otherwise the build fails when HID_PICOLCD=y and LCD_CLASS_DEVICE=m:hid-picolcd.c:(.text+0x84523f): undefined reference to
lcd_device_unregister' hid-picolcd.c:(.text+0x8478ab): undefined reference tolcd_device_register' hid-picolcd.c:(.text+0x84c15f): undefined reference to `lcd_device_unregister'Reported-by Randy Dunlap <[email protected]>Signed-off-by Bruno Prémont <[email protected]>drivers/hid/Kconfig +0
-0
drivers/hid/Kconfig config HID_PICOLCD · line 287
Quoted 3 lines
drivers/hid/Kconfig +0
-0@@ -285,6 +285,35 @@ config HID_PICOLCD Features that are not (yet) supported: - IR
All of these user-visible kconfig options need help text also...
Quoted 22 lines
drivers/hid/Kconfig +22
-0+config HID_PICOLCD_FB + bool "Framebuffer support" + default !EMBEDDED + depends on HID_PICOLCD + depends on HID_PICOLCD=FB || FB=y + select FB_DEFERRED_IO + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + +config HID_PICOLCD_BACKLIGHT + bool "Backlight control" + default !EMBEDDED + depends on HID_PICOLCD + depends on HID_PICOLCD=BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=y + +config HID_PICOLCD_LCD + bool "Contrast control" + default !EMBEDDED + depends on HID_PICOLCD + depends on HID_PICOLCD=LCD_CLASS_DEVICE || LCD_CLASS_DEVICE=y
drivers/hid/Kconfig config HID_PICOLCD · line 319
Quoted 10 lines
drivers/hid/Kconfig +7
-0+ +config HID_PICOLCD_LEDS + bool "GPO via leds class" + default !EMBEDDED + depends on HID_PICOLCD + depends on HID_PICOLCD=LEDS_CLASS || LEDS_CLASS=y + config HID_QUANTA tristate "Quanta Optical Touch" depends on USB_HID
---
~Randy
Bruno Prémont
maintainerRe: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE
HID_PICOLCD should depend on LCD_CLASS_DEVICE, otherwise the build fails when HID_PICOLCD=y and LCD_CLASS_DEVICE=m:
hid-picolcd.c:(.text+0x84523f): undefined reference to lcd_device_unregister' hid-picolcd.c:(.text+0x8478ab): undefined reference to lcd_device_register' hid-picolcd.c:(.text+0x84c15f): undefined reference to `lcd_device_unregister'
Same applies to FB, BACKLIGHT_CLASS_DEVICE and LEDS_CLASS.
Add suboptions for those features to handle the deps on kbuild side and just check HID_PICOLCD_* in the code.
---
Quoted 2 lines · On Wed, 07 April 2010 Randy Dunlap <[email protected]> wrote:
All of these user-visible kconfig options need help text also...
Here is a better patch, with added documentation and stripped select clauses under HID_PICOLCD as they are handled by HID_PICOLCD_FB.
drivers/hid/Kconfig | 53 +++++++++++++++++++++++++++++++++++++------- drivers/hid/hid-picolcd.c | 40 +++++++++++++++++----------------- 2 files changed, 64 insertions(+), 29 deletions(-)
drivers/hid/Kconfig +44 -9
@@ -265,11 +265,6 @@ config HID_PETALYNX config HID_PICOLCD tristate "PicoLCD (graphic version)" depends on USB_HID - select FB_DEFERRED_IO if FB - select FB_SYS_FILLRECT if FB - select FB_SYS_COPYAREA if FB - select FB_SYS_IMAGEBLIT if FB - select FB_SYS_FOPS if FB ---help--- This provides support for Minibox PicoLCD devices, currently only the graphical ones are supported.
@@ -277,14 +272,54 @@ config HID_PICOLCD This includes support for the following device features: - Keypad - Switching between Firmware and Flash mode - - Framebuffer for monochrome 256x64 display - - Backlight control (needs CONFIG_BACKLIGHT_CLASS_DEVICE) - - Contrast control (needs CONFIG_LCD_CLASS_DEVICE) - - General purpose outputs (needs CONFIG_LEDS_CLASS) - EEProm / Flash access (via debugfs) + Features to selectively enable: + - Framebuffer for monochrome 256x64 display + - Backlight control + - Contrast control + - General purpose outputs Features that are not (yet) supported: - IR +config HID_PICOLCD_FB + bool "Framebuffer support" + default !EMBEDDED + depends on HID_PICOLCD + depends on HID_PICOLCD=FB || FB=y + select FB_DEFERRED_IO + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + ---help--- + Provide access to PicoLCD's 256x64 monochrome display via a + frambuffer device. + +config HID_PICOLCD_BACKLIGHT + bool "Backlight control" + default !EMBEDDED + depends on HID_PICOLCD + depends on HID_PICOLCD=BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=y + ---help--- + Provide access to PicoLCD's backlight control via backlight + class. + +config HID_PICOLCD_LCD + bool "Contrast control" + default !EMBEDDED + depends on HID_PICOLCD + depends on HID_PICOLCD=LCD_CLASS_DEVICE || LCD_CLASS_DEVICE=y + ---help--- + Provide access to PicoLCD's LCD contrast via lcd class. + +config HID_PICOLCD_LEDS + bool "GPO via leds class" + default !EMBEDDED + depends on HID_PICOLCD + depends on HID_PICOLCD=LEDS_CLASS || LEDS_CLASS=y + ---help--- + Provide access to PicoLCD's GPO pins via leds class. + config HID_QUANTA tristate "Quanta Optical Touch" depends on USB_HID
drivers/hid/hid-picolcd.c +20 -20
@@ -77,7 +77,7 @@#define REPORT_HOOK_VERSION 0xf7/* LCD: IN[2], OUT[1] */ #define REPORT_EXIT_FLASHER 0xff/* Bootloader: OUT[2] */ -#if defined(CONFIG_FB ) || defined(CONFIG_FB_MODULE ) +#ifdef CONFIG_HID_PICOLCD_FB /* Framebuffer * * The PicoLCD use a Topway LCD module of 256x64 pixel
@@ -128,7 +128,7 @@ static const struct fb_var_screeninfo picolcdfb_var = { .bits_per_pixel = 1, .grayscale = 1, }; -#endif /* CONFIG_FB */ +#endif /* CONFIG_HID_PICOLCD_FB */ /* Input device *
@@ -183,7 +183,7 @@ struct picolcd_data {struct input_dev *input_cir;unsigned short keycode[PICOLCD_KEYS ]; -#if defined(CONFIG_FB ) || defined(CONFIG_FB_MODULE ) +#ifdef CONFIG_HID_PICOLCD_FB /* Framebuffer stuff */ u8 fb_update_rate;u8 fb_bpp;
@@ -191,21 +191,21 @@ struct picolcd_data {u8 *fb_bitmap;/* framebuffer */ struct fb_info *fb_info;struct fb_deferred_io fb_defio; -#endif /* CONFIG_FB */ -#if defined(CONFIG_LCD_CLASS_DEVICE ) || defined(CONFIG_LCD_CLASS_DEVICE_MODULE ) +#endif /* CONFIG_HID_PICOLCD_FB */ +#ifdef CONFIG_HID_PICOLCD_LCD struct lcd_device *lcd;u8 lcd_contrast; -#endif -#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE ) || defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE ) +#endif /* CONFIG_HID_PICOLCD_LCD */ +#ifdef CONFIG_HID_PICOLCD_BACKLIGHT struct backlight_device *backlight;u8 lcd_brightness;u8 lcd_power; -#endif /* CONFIG_BACKLIGHT_CLASS_DEVICE */ -#if defined(CONFIG_LEDS_CLASS ) || defined(CONFIG_LEDS_CLASS_MODULE ) +#endif /* CONFIG_HID_PICOLCD_BACKLIGHT */ +#ifdef CONFIG_HID_PICOLCD_LEDS /* LED stuff */ u8 led_state;struct led_classdev *led[8 ]; -#endif /* CONFIG_LEDS_CLASS */ +#endif /* CONFIG_HID_PICOLCD_LEDS */ /* Housekeeping stuff */ spinlock_t lock;
@@ -287,7 +287,7 @@ static struct picolcd_pending *picolcd_send_and_wait(struct hid_device *hdev,return work; } -#if defined(CONFIG_FB ) || defined(CONFIG_FB_MODULE ) +#ifdef CONFIG_HID_PICOLCD_FB /* Send a given tile to PicoLCD */ static int picolcd_fb_send_tile (struct hid_device *hdev,int chip,int tile) {
@@ -766,9 +766,9 @@ static void picolcd_exit_framebuffer(struct picolcd_data *data) { }#define picolcd_fbinfo (d) NULL -#endif /* CONFIG_FB */ +#endif /* CONFIG_HID_PICOLCD_FB */ -#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE ) || defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE ) +#ifdef CONFIG_HID_PICOLCD_BACKLIGHT /* * backlight class device */
@@ -864,9 +864,9 @@ static inline int picolcd_resume_backlight(struct picolcd_data *data) {return 0 ; } -#endif /* CONFIG_BACKLIGHT_CLASS_DEVICE */ +#endif /* CONFIG_HID_PICOLCD_BACKLIGHT */ -#if defined(CONFIG_LCD_CLASS_DEVICE ) || defined(CONFIG_LCD_CLASS_DEVICE_MODULE ) +#ifdef CONFIG_HID_PICOLCD_LCD /* * lcd class device */
@@ -957,9 +957,9 @@ static inline int picolcd_resume_lcd(struct picolcd_data *data) {return 0 ; } -#endif /* CONFIG_LCD_CLASS_DEVICE */ +#endif /* CONFIG_HID_PICOLCD_LCD */ -#if defined(CONFIG_LEDS_CLASS ) || defined(CONFIG_LEDS_CLASS_MODULE ) +#ifdef CONFIG_HID_PICOLCD_LEDS /** * LED class device */
@@ -1104,7 +1104,7 @@ static inline int picolcd_leds_set(struct picolcd_data *data) {return 0 ; } -#endif /* CONFIG_LEDS_CLASS */ +#endif /* CONFIG_HID_PICOLCD_LEDS */ /* * input class device
@@ -1243,10 +1243,10 @@ static int picolcd_reset(struct hid_device *hdev)picolcd_resume_lcd (data);picolcd_resume_backlight (data); -#if defined(CONFIG_FB ) || defined(CONFIG_FB_MODULE ) +#ifdef CONFIG_HID_PICOLCD_FB if (data->fb_info)schedule_delayed_work (&data->fb_info->deferred_work,0 ); -#endif /* CONFIG_FB */ +#endif /* CONFIG_HID_PICOLCD_FB */ picolcd_leds_set (data);return 0 ;
Signature · 6 lines
1.6.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE
Quoted 63 lines · Bruno Prémont
HID_PICOLCDshould depend onLCD_CLASS_DEVICE, otherwise the build fails when HID_PICOLCD=y and LCD_CLASS_DEVICE=m:hid-picolcd.c:(.text+0x84523f): undefined reference to
lcd_device_unregister' hid-picolcd.c:(.text+0x8478ab): undefined reference tolcd_device_register' hid-picolcd.c:(.text+0x84c15f): undefined reference to `lcd_device_unregister'Same applies to FB,
BACKLIGHT_CLASS_DEVICEandLEDS_CLASS.Add suboptions for those features to handle the deps on kbuild side and just check HID_PICOLCD_* in the code.
Reported-by Randy Dunlap <[email protected]>Signed-off-by Bruno Prémont <[email protected]>---
Quoted 2 lines · On Wed, 07 April 2010 Randy Dunlap <[email protected]> wrote:
All of these user-visible kconfig options need help text also...
Here is a better patch, with added documentation and stripped select clauses under
HID_PICOLCDas they are handled byHID_PICOLCD_FB.drivers/hid/Kconfig | 53 +++++++++++++++++++++++++++++++++++++------- drivers/hid/hid-picolcd.c | 40 +++++++++++++++++----------------- 2 files changed, 64 insertions(+), 29 deletions(-)drivers/hid/Kconfig +5
-9@@ -265,11 +265,6 @@ config HID_PETALYNX config HID_PICOLCD tristate "PicoLCD (graphic version)" depends on USB_HID - select FB_DEFERRED_IO if FB - select FB_SYS_FILLRECT if FB - select FB_SYS_COPYAREA if FB - select FB_SYS_IMAGEBLIT if FB - select FB_SYS_FOPS if FB ---help--- This provides support for Minibox PicoLCD devices, currently only the graphical ones are supported.@@ -277,14 +272,54 @@ config HID_PICOLCD This includes support for the following device features: - Keypad - Switching between Firmware and Flash mode - - Framebuffer for monochrome 256x64 display - - Backlight control (needs CONFIG_BACKLIGHT_CLASS_DEVICE) - - Contrast control (needs CONFIG_LCD_CLASS_DEVICE) - - General purpose outputs (needs CONFIG_LEDS_CLASS) - EEProm / Flash access (via debugfs) + Features to selectively enable: + - Framebuffer for monochrome 256x64 display + - Backlight control + - Contrast control + - General purpose outputs Features that are not (yet) supported: - IR
drivers/hid/Kconfig config HID_PICOLCD · line 293
Quoted 10 lines
drivers/hid/Kconfig +10
-0+config HID_PICOLCD_FB + bool "Framebuffer support" + default !EMBEDDED + depends on HID_PICOLCD + depends on HID_PICOLCD=FB || FB=y + select FB_DEFERRED_IO + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS
Could we perhaps also make the sub-choices for individual features availabel only if !EMBEDDED as well?
It's probably too much to ask for a single device during oldconfig run, for example ...
Thanks,
Signature · 6 lines
Jiri Kosina SUSE Labs, Novell Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Bruno Prémont
maintainerRe: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE
HID_PICOLCD should depend on LCD_CLASS_DEVICE, otherwise the build fails when HID_PICOLCD=y and LCD_CLASS_DEVICE=m:
hid-picolcd.c:(.text+0x84523f): undefined reference to lcd_device_unregister' hid-picolcd.c:(.text+0x8478ab): undefined reference to lcd_device_register' hid-picolcd.c:(.text+0x84c15f): undefined reference to `lcd_device_unregister'
Same applies to FB, BACKLIGHT_CLASS_DEVICE and LEDS_CLASS.
Add suboptions for those features to handle the deps on kbuild side and just check HID_PICOLCD_* in the code.
---
Quoted 5 lines · On Thu, 08 April 2010 Jiri Kosina <[email protected]> wrote:
Quoted 5 lines
(quoted diff) +5
-0+config HID_PICOLCD_FB + bool "Framebuffer support" + default !EMBEDDED + depends on HID_PICOLCD + depends on HID_PICOLCD=FB || FB=y
Quoted 8 lines
Review
Quoted 5 lines
(quoted diff) +5
-0+ select FB_DEFERRED_IO + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPSCould we perhaps also make the sub-choices for individual features availabel only if !EMBEDDED as well?
Here is an updated patch to make the sub-choices visible only in EMBEDDED case.
Thanks,
Bruno
drivers/hid/Kconfig | 53 +++++++++++++++++++++++++++++++++++++------- drivers/hid/hid-picolcd.c | 40 +++++++++++++++++----------------- 2 files changed, 64 insertions(+), 29 deletions(-)
drivers/hid/Kconfig +44 -9
@@ -265,11 +265,6 @@ config HID_PETALYNX config HID_PICOLCD tristate "PicoLCD (graphic version)" depends on USB_HID - select FB_DEFERRED_IO if FB - select FB_SYS_FILLRECT if FB - select FB_SYS_COPYAREA if FB - select FB_SYS_IMAGEBLIT if FB - select FB_SYS_FOPS if FB ---help--- This provides support for Minibox PicoLCD devices, currently only the graphical ones are supported.
@@ -277,14 +272,54 @@ config HID_PICOLCD This includes support for the following device features: - Keypad - Switching between Firmware and Flash mode - - Framebuffer for monochrome 256x64 display - - Backlight control (needs CONFIG_BACKLIGHT_CLASS_DEVICE) - - Contrast control (needs CONFIG_LCD_CLASS_DEVICE) - - General purpose outputs (needs CONFIG_LEDS_CLASS) - EEProm / Flash access (via debugfs) + Features selectively enabled: + - Framebuffer for monochrome 256x64 display + - Backlight control + - Contrast control + - General purpose outputs Features that are not (yet) supported: - IR +config HID_PICOLCD_FB + bool "Framebuffer support" if EMBEDDED + default !EMBEDDED + depends on HID_PICOLCD + depends on HID_PICOLCD=FB || FB=y + select FB_DEFERRED_IO + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + ---help--- + Provide access to PicoLCD's 256x64 monochrome display via a + frambuffer device. + +config HID_PICOLCD_BACKLIGHT + bool "Backlight control" if EMBEDDED + default !EMBEDDED + depends on HID_PICOLCD + depends on HID_PICOLCD=BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=y + ---help--- + Provide access to PicoLCD's backlight control via backlight + class. + +config HID_PICOLCD_LCD + bool "Contrast control" if EMBEDDED + default !EMBEDDED + depends on HID_PICOLCD + depends on HID_PICOLCD=LCD_CLASS_DEVICE || LCD_CLASS_DEVICE=y + ---help--- + Provide access to PicoLCD's LCD contrast via lcd class. + +config HID_PICOLCD_LEDS + bool "GPO via leds class" if EMBEDDED + default !EMBEDDED + depends on HID_PICOLCD + depends on HID_PICOLCD=LEDS_CLASS || LEDS_CLASS=y + ---help--- + Provide access to PicoLCD's GPO pins via leds class. + config HID_QUANTA tristate "Quanta Optical Touch" depends on USB_HID
drivers/hid/hid-picolcd.c +20 -20
@@ -77,7 +77,7 @@#define REPORT_HOOK_VERSION 0xf7/* LCD: IN[2], OUT[1] */ #define REPORT_EXIT_FLASHER 0xff/* Bootloader: OUT[2] */ -#if defined(CONFIG_FB ) || defined(CONFIG_FB_MODULE ) +#ifdef CONFIG_HID_PICOLCD_FB /* Framebuffer * * The PicoLCD use a Topway LCD module of 256x64 pixel
@@ -128,7 +128,7 @@ static const struct fb_var_screeninfo picolcdfb_var = { .bits_per_pixel = 1, .grayscale = 1, }; -#endif /* CONFIG_FB */ +#endif /* CONFIG_HID_PICOLCD_FB */ /* Input device *
@@ -183,7 +183,7 @@ struct picolcd_data {struct input_dev *input_cir;unsigned short keycode[PICOLCD_KEYS ]; -#if defined(CONFIG_FB ) || defined(CONFIG_FB_MODULE ) +#ifdef CONFIG_HID_PICOLCD_FB /* Framebuffer stuff */ u8 fb_update_rate;u8 fb_bpp;
@@ -191,21 +191,21 @@ struct picolcd_data {u8 *fb_bitmap;/* framebuffer */ struct fb_info *fb_info;struct fb_deferred_io fb_defio; -#endif /* CONFIG_FB */ -#if defined(CONFIG_LCD_CLASS_DEVICE ) || defined(CONFIG_LCD_CLASS_DEVICE_MODULE ) +#endif /* CONFIG_HID_PICOLCD_FB */ +#ifdef CONFIG_HID_PICOLCD_LCD struct lcd_device *lcd;u8 lcd_contrast; -#endif -#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE ) || defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE ) +#endif /* CONFIG_HID_PICOLCD_LCD */ +#ifdef CONFIG_HID_PICOLCD_BACKLIGHT struct backlight_device *backlight;u8 lcd_brightness;u8 lcd_power; -#endif /* CONFIG_BACKLIGHT_CLASS_DEVICE */ -#if defined(CONFIG_LEDS_CLASS ) || defined(CONFIG_LEDS_CLASS_MODULE ) +#endif /* CONFIG_HID_PICOLCD_BACKLIGHT */ +#ifdef CONFIG_HID_PICOLCD_LEDS /* LED stuff */ u8 led_state;struct led_classdev *led[8 ]; -#endif /* CONFIG_LEDS_CLASS */ +#endif /* CONFIG_HID_PICOLCD_LEDS */ /* Housekeeping stuff */ spinlock_t lock;
@@ -287,7 +287,7 @@ static struct picolcd_pending *picolcd_send_and_wait(struct hid_device *hdev,return work; } -#if defined(CONFIG_FB ) || defined(CONFIG_FB_MODULE ) +#ifdef CONFIG_HID_PICOLCD_FB /* Send a given tile to PicoLCD */ static int picolcd_fb_send_tile (struct hid_device *hdev,int chip,int tile) {
@@ -766,9 +766,9 @@ static void picolcd_exit_framebuffer(struct picolcd_data *data) { }#define picolcd_fbinfo (d) NULL -#endif /* CONFIG_FB */ +#endif /* CONFIG_HID_PICOLCD_FB */ -#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE ) || defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE ) +#ifdef CONFIG_HID_PICOLCD_BACKLIGHT /* * backlight class device */
@@ -864,9 +864,9 @@ static inline int picolcd_resume_backlight(struct picolcd_data *data) {return 0 ; } -#endif /* CONFIG_BACKLIGHT_CLASS_DEVICE */ +#endif /* CONFIG_HID_PICOLCD_BACKLIGHT */ -#if defined(CONFIG_LCD_CLASS_DEVICE ) || defined(CONFIG_LCD_CLASS_DEVICE_MODULE ) +#ifdef CONFIG_HID_PICOLCD_LCD /* * lcd class device */
@@ -957,9 +957,9 @@ static inline int picolcd_resume_lcd(struct picolcd_data *data) {return 0 ; } -#endif /* CONFIG_LCD_CLASS_DEVICE */ +#endif /* CONFIG_HID_PICOLCD_LCD */ -#if defined(CONFIG_LEDS_CLASS ) || defined(CONFIG_LEDS_CLASS_MODULE ) +#ifdef CONFIG_HID_PICOLCD_LEDS /** * LED class device */
@@ -1104,7 +1104,7 @@ static inline int picolcd_leds_set(struct picolcd_data *data) {return 0 ; } -#endif /* CONFIG_LEDS_CLASS */ +#endif /* CONFIG_HID_PICOLCD_LEDS */ /* * input class device
@@ -1243,10 +1243,10 @@ static int picolcd_reset(struct hid_device *hdev)picolcd_resume_lcd (data);picolcd_resume_backlight (data); -#if defined(CONFIG_FB ) || defined(CONFIG_FB_MODULE ) +#ifdef CONFIG_HID_PICOLCD_FB if (data->fb_info)schedule_delayed_work (&data->fb_info->deferred_work,0 ); -#endif /* CONFIG_FB */ +#endif /* CONFIG_HID_PICOLCD_FB */ picolcd_leds_set (data);return 0 ;
Signature · 6 lines
1.6.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Jiri Kosina
AppliedRe: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE
Quoted 14 lines · Bruno Prémont
Quoted 5 lines
Quoted 5 lines
drivers/hid/Kconfig +5
-0+config HID_PICOLCD_FB + bool "Framebuffer support" + default !EMBEDDED + depends on HID_PICOLCD + depends on HID_PICOLCD=FB || FB=yQuoted 8 lines
drivers/hid/Kconfig config HID_PICOLCD · line 293
Quoted 5 lines
drivers/hid/Kconfig +5
-0+ select FB_DEFERRED_IO + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPSCould we perhaps also make the sub-choices for individual features availabel only if !EMBEDDED as well?
Quoted 2 lines
Here is an updated patch to make the sub-choices visible only in EMBEDDED case.
Applied, thanks Bruno.
Signature · 6 lines
Jiri Kosina SUSE Labs, Novell Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Bruno Prémont
maintainerRe: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE
In reply to Randy DunlapQuoted 9 lines · On Tue, 06 April 2010 Randy Dunlap <[email protected]> wrote:
Quoted 3 lines
One of my attempts did end up with a circular loop with regard to FB (some of the FB drivers did select INPUT)?
(not that I can find)
CONFIG_VTdoes select INPUT
andCONFIG_DRM_I915does
select INPUT if ACPI
A newer attempt still produces the same result:
drivers/input/Kconfig:9:error: found recursive dependency: INPUT ->
HID_SUPPORT -> HID_PICOLCD_FB -> FB -> FB_STI -> VT -> INPUT
(it's only FB which causes the loop, LEDS, LCD and BACKLIGHT are fine)
This is with following patch on top of the improved deps patch I sent a few minutes ago deeper in this thread.
Is there a way around this?
drivers/hid/Kconfig +7 -4
@@ -285,7 +285,7 @@ config HID_PICOLCD_FB bool "Framebuffer support" default !EMBEDDED depends on HID_PICOLCD - depends on HID_PICOLCD=FB || FB=y + select FB select FB_DEFERRED_IO select FB_SYS_FILLRECT select FB_SYS_COPYAREA
@@ -299,7 +299,8 @@ config HID_PICOLCD_BACKLIGHT bool "Backlight control" default !EMBEDDED depends on HID_PICOLCD - depends on HID_PICOLCD=BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=y + select BACKLIGHT_LCD_SUPPORT + select BACKLIGHT_CLASS_DEVICE ---help--- Provide access to PicoLCD's backlight control via backlight class.
@@ -308,7 +309,8 @@ config HID_PICOLCD_LCD bool "Contrast control" default !EMBEDDED depends on HID_PICOLCD - depends on HID_PICOLCD=LCD_CLASS_DEVICE || LCD_CLASS_DEVICE=y + select BACKLIGHT_LCD_SUPPORT + select LCD_CLASS_DEVICE ---help--- Provide access to PicoLCD's LCD contrast via lcd class.
@@ -316,7 +318,8 @@ config HID_PICOLCD_LEDS bool "GPO via leds class" default !EMBEDDED depends on HID_PICOLCD - depends on HID_PICOLCD=LEDS_CLASS || LEDS_CLASS=y + select NEW_LEDS + select LEDS_CLASS ---help--- Provide access to PicoLCD's GPO pins via leds class.
Re: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE
Quoted 11 lines · On Wed, 7 Apr 2010 20:44:04 +0200 Bruno Prémont wrote:
Quoted 9 lines · On Tue, 06 April 2010 Randy Dunlap <[email protected]> wrote:
Quoted 3 lines
One of my attempts did end up with a circular loop with regard to FB (some of the FB drivers did select INPUT)?
(not that I can find)
CONFIG_VTdoes select INPUT
andCONFIG_DRM_I915does
select INPUT if ACPI
Quoted 6 lines
A newer attempt still produces the same result:
drivers/input/Kconfig:9:error: found recursive dependency: INPUT ->
HID_SUPPORT -> HID_PICOLCD_FB -> FB -> FB_STI -> VT -> INPUT(it's only FB which causes the loop, LEDS, LCD and BACKLIGHT are fine)
(yes, so I see)
Quoted 5 lines
This is with following patch on top of the improved deps patch I sent a few minutes ago deeper in this thread.
Is there a way around this?
Well, lesson #1 is that select is evil^W^W should only be used to enable library-like code, or as Documentation/kbuild/kconfig-language.txt says:
Note:
select should be used with care. select will force a symbol to a value without visiting the dependencies. By abusing select you are able to select a symbol FOO even if FOO depends on BAR that is not set.
In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies. That will limit the usefulness but on the other hand avoid the illegal configurations all over.
kconfig should one day warn about such things.
(more below)
drivers/hid/Kconfig config HID_PICOLCD_FB · line 288
Quoted 11 lines
drivers/hid/Kconfig +1
-1@@ -285,7 +285,7 @@ config HID_PICOLCD_FB bool "Framebuffer support" default !EMBEDDED depends on HID_PICOLCD - depends on HID_PICOLCD=FB || FB=y + select FB
If you'll go back to the unpatched (by this patch) version here, it seems to work OK.
Quoted 24 lines
drivers/hid/Kconfig +4
-2select FB_DEFERRED_IO select FB_SYS_FILLRECT select FB_SYS_COPYAREA@@ -299,7 +299,8 @@ config HID_PICOLCD_BACKLIGHT bool "Backlight control" default !EMBEDDED depends on HID_PICOLCD - depends on HID_PICOLCD=BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=y + select BACKLIGHT_LCD_SUPPORT + select BACKLIGHT_CLASS_DEVICE ---help--- Provide access to PicoLCD's backlight control via backlight class.@@ -308,7 +309,8 @@ config HID_PICOLCD_LCD bool "Contrast control" default !EMBEDDED depends on HID_PICOLCD - depends on HID_PICOLCD=LCD_CLASS_DEVICE || LCD_CLASS_DEVICE=y + select BACKLIGHT_LCD_SUPPORT + select LCD_CLASS_DEVICE ---help--- Provide access to PicoLCD's LCD contrast via lcd class.
drivers/hid/Kconfig config HID_PICOLCD_LEDS · line 324
Quoted 8 lines
drivers/hid/Kconfig +2
-1@@ -316,7 +318,8 @@ config HID_PICOLCD_LEDS bool "GPO via leds class" default !EMBEDDED depends on HID_PICOLCD - depends on HID_PICOLCD=LEDS_CLASS || LEDS_CLASS=y + select NEW_LEDS + select LEDS_CLASS ---help--- Provide access to PicoLCD's GPO pins via leds class.
---
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Bruno Prémont
maintainerRe: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE
Quoted 31 lines · On Wed, 07 April 2010 Randy Dunlap <[email protected]> wrote:
Quoted 11 lines · On Wed, 7 Apr 2010 20:44:04 +0200 Bruno Prémont wrote:
Quoted 9 lines · On Tue, 06 April 2010 Randy Dunlap <[email protected]> wrote:
Quoted 3 lines
One of my attempts did end up with a circular loop with regard to FB (some of the FB drivers did select INPUT)?
(not that I can find)
CONFIG_VTdoes select INPUT
andCONFIG_DRM_I915does
select INPUT if ACPIQuoted 6 lines
A newer attempt still produces the same result:
drivers/input/Kconfig:9:error: found recursive dependency: INPUT ->
HID_SUPPORT -> HID_PICOLCD_FB -> FB -> FB_STI -> VT -> INPUT(it's only FB which causes the loop, LEDS, LCD and BACKLIGHT are fine)
(yes, so I see)
Quoted 5 lines
This is with following patch on top of the improved deps patch I sent a few minutes ago deeper in this thread.
Is there a way around this?
Well, lesson #1 is that select is evil^W^W should only be used to enable library-like code, or as
Documentation/kbuild/kconfig-language.txtsays:
Quoted 10 lines
Note:
select should be used with care. select will force a symbol to a value without visiting the dependencies. By abusing select you are able to select a symbol FOO even if FOO depends on BAR that is not set.
In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies. That will limit the usefulness but on the other hand avoid the illegal configurations all over.
kconfig should one day warn about such things.
I've read that paragraph and I would definitely prefer not to have to use select for what this patch should achieve!
It should really be a helper for the user going through menuconfig like "please check all what is needed to satisfy this item's dependencies" A "try-select-deep" or whatever it could be called.
A well-behaved "GUI" implementation of this would show what would get newly checked and give the user the opportunity to not proceed or fine-tune y/m choices.
Quoted 16 lines
(more below)
drivers/hid/Kconfig config HID_PICOLCD_FB · line 288
Quoted 11 lines
drivers/hid/Kconfig +1
-1@@ -285,7 +285,7 @@ config HID_PICOLCD_FB bool "Framebuffer support" default !EMBEDDED depends on HID_PICOLCD - depends on HID_PICOLCD=FB || FB=y + select FBIf you'll go back to the unpatched (by this patch) version here, it seems to work OK.
So best is probably to just forget about all of this non-leaf select usage for now. (and not have one half doing one way and the other half doing it the other way)
Thanks,
Bruno
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 3 lines · On Mon, 05 Apr 2010 16:09:45 PDT, [email protected] said:
The mm-of-the-moment snapshot 2010-04-05-16-09 has been uploaded to
Seen in dmesg, 2.6.34-rc2-mmotm0323 didn't do this. Tossing it at all the likely suspects, hopefully somebody will recognize it and save me the bisecting. ;)
[ 11.488535] ctnetlink v0.93: registering with nfnetlink.
[ 11.488579]
[ 11.488579] ===================================================
[ 11.489529] [ INFO: suspicious rcu_dereference_check() usage. ]
[ 11.489988] ---------------------------------------------------
[ 11.490494] net/netfilter/nf_conntrack_ecache.c:88 invoked rcu_dereference_check() without protection!
[ 11.491024]
[ 11.491024] other info that might help us debug this:
[ 11.491025]
[ 11.492834]
[ 11.492835] rcu_scheduler_active = 1, debug_locks = 0
[ 11.494124] 1 lock held by swapper/1:
[ 11.494776] #0: (nf_ct_ecache_mutex){+.+...}, at: [<ffffffff8148c606>] nf_conntrack_register_notifier+0x1a/0x76
[ 11.495505]
[ 11.495506] stack backtrace:
[ 11.496927] Pid: 1, comm: swapper Not tainted 2.6.34-rc3-mmotm0405 #1
[ 11.497668] Call Trace:
[ 11.498419] [<ffffffff810638c5>] lockdep_rcu_dereference+0xaa/0xb2
[ 11.499185] [<ffffffff8148c629>] nf_conntrack_register_notifier+0x3d/0x76
[ 11.499967] [<ffffffff81b5dd7b>] ctnetlink_init+0x71/0xd5
[ 11.500775] [<ffffffff81b5dd0a>] ? ctnetlink_init+0x0/0xd5
[ 11.501579] [<ffffffff810001ef>] do_one_initcall+0x59/0x14e
[ 11.502396] [<ffffffff81b3268a>] kernel_init+0x144/0x1ce
[ 11.503218] [<ffffffff81003514>] kernel_thread_helper+0x4/0x10
[ 11.504047] [<ffffffff8159cc00>] ? restore_args+0x0/0x30
[ 11.504882] [<ffffffff81b32546>] ? kernel_init+0x0/0x1ce
[ 11.505715] [<ffffffff81003510>] ? kernel_thread_helper+0x0/0x10
[ 11.506636] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 11.507372] TCP bic registeredQuoted 9 lines · [email protected] wrote:
Quoted 3 lines · On Mon, 05 Apr 2010 16:09:45 PDT, [email protected] said:
The mm-of-the-moment snapshot 2010-04-05-16-09 has been uploaded to
Seen in dmesg, 2.6.34-rc2-mmotm0323 didn't do this. Tossing it at all the likely suspects, hopefully somebody will recognize it and save me the bisecting. ;)
Quoted 14 lines
[ 11.488535] ctnetlink v0.93: registering with nfnetlink.
[ 11.488579]
[ 11.488579] ===================================================
[ 11.489529] [ INFO: suspicious rcu_dereference_check() usage. ]
[ 11.489988] ---------------------------------------------------
[ 11.490494] net/netfilter/nf_conntrack_ecache.c:88 invoked rcu_dereference_check() without protection!
[ 11.491024]
[ 11.491024] other info that might help us debug this:
[ 11.491025]
[ 11.492834]
[ 11.492835] rcu_scheduler_active = 1, debug_locks = 0
[ 11.494124] 1 lock held by swapper/1:
[ 11.494776] #0: (nf_ct_ecache_mutex){+.+...}, at: [<ffffffff8148c606>] nf_conntrack_register_notifier+0x1a/0x76
[ 11.495505] There are some unnecessary rcu_dereference() calls in the conntrack notifier registration and unregistration functions.
Does this fix it?
net/netfilter/nf_conntrack_ecache.c +4 -14
@@ -81,11 +81,9 @@ EXPORT_SYMBOL_GPL(nf_ct_deliver_cached_events);int nf_conntrack_register_notifier (struct nf_ct_event_notifier *new) {int ret =0 ; -struct nf_ct_event_notifier *notify;mutex_lock (&nf_ct_ecache_mutex); - notify =rcu_dereference (nf_conntrack_event_cb); -if (notify !=NULL ) { +if (nf_conntrack_event_cb !=NULL ) { ret = -EBUSY ; goto out_unlock; }
@@ -101,11 +99,8 @@ EXPORT_SYMBOL_GPL(nf_conntrack_register_notifier);void nf_conntrack_unregister_notifier (struct nf_ct_event_notifier *new) { -struct nf_ct_event_notifier *notify; -mutex_lock (&nf_ct_ecache_mutex); - notify =rcu_dereference (nf_conntrack_event_cb); -BUG_ON (notify != new); +BUG_ON (nf_conntrack_event_cb != new);rcu_assign_pointer (nf_conntrack_event_cb,NULL );mutex_unlock (&nf_ct_ecache_mutex); }
@@ -114,11 +109,9 @@ EXPORT_SYMBOL_GPL(nf_conntrack_unregister_notifier);int nf_ct_expect_register_notifier (struct nf_exp_event_notifier *new) {int ret =0 ; -struct nf_exp_event_notifier *notify;mutex_lock (&nf_ct_ecache_mutex); - notify =rcu_dereference (nf_expect_event_cb); -if (notify !=NULL ) { +if (nf_expect_event_cb !=NULL ) { ret = -EBUSY ; goto out_unlock; }
@@ -134,11 +127,8 @@ EXPORT_SYMBOL_GPL(nf_ct_expect_register_notifier);void nf_ct_expect_unregister_notifier (struct nf_exp_event_notifier *new) { -struct nf_exp_event_notifier *notify; -mutex_lock (&nf_ct_ecache_mutex); - notify =rcu_dereference (nf_expect_event_cb); -BUG_ON (notify != new); +BUG_ON (nf_expect_event_cb != new);rcu_assign_pointer (nf_expect_event_cb,NULL );mutex_unlock (&nf_ct_ecache_mutex); }
Quoted 25 lines · Patrick McHardy
Quoted 9 lines · [email protected] wrote:
Quoted 3 lines · On Mon, 05 Apr 2010 16:09:45 PDT, [email protected] said:
The mm-of-the-moment snapshot 2010-04-05-16-09 has been uploaded to
Seen in dmesg, 2.6.34-rc2-mmotm0323 didn't do this. Tossing it at all the likely suspects, hopefully somebody will recognize it and save me the bisecting. ;)
Quoted 14 lines
[ 11.488535] ctnetlink v0.93: registering with nfnetlink. [ 11.488579] [ 11.488579] =================================================== [ 11.489529] [ INFO: suspicious rcu_dereference_check() usage. ] [ 11.489988] --------------------------------------------------- [ 11.490494] net/netfilter/nf_conntrack_ecache.c:88 invoked rcu_dereference_check() without protection! [ 11.491024] [ 11.491024] other info that might help us debug this: [ 11.491025] [ 11.492834] [ 11.492835] rcu_scheduler_active = 1, debug_locks = 0 [ 11.494124] 1 lock held by swapper/1: [ 11.494776] #0: (nf_ct_ecache_mutex){+.+...}, at: [<ffffffff8148c606>] nf_conntrack_register_notifier+0x1a/0x76 [ 11.495505]
Quoted 4 lines
There are some unnecessary
rcu_dereference()calls in the conntrack notifier registration and unregistration functions.Does this fix it?
Well, it *changed* it. Does the rcu_defererence_check() only fire on the first time it hits something, so we've fixed the first one and now we get to see the second one?
(For what it's worth, if this is going to be one-at-a-time whack-a-mole, I'm OK on that, just want to know up front.)
[ 9.299425] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 9.299486]
[ 9.299486] ===================================================
[ 9.300499] [ INFO: suspicious rcu_dereference_check() usage. ]
[ 9.301001] ---------------------------------------------------
[ 9.301523] net/netfilter/nf_log.c:55 invoked rcu_dereference_check() without protection!
[ 9.302066]
[ 9.302066] other info that might help us debug this:
[ 9.302067]
[ 9.303748]
[ 9.303748] rcu_scheduler_active = 1, debug_locks = 0
[ 9.304990] 1 lock held by swapper/1:
[ 9.305645] #0: (nf_log_mutex){+.+...}, at: [<ffffffff8148427a>] nf_log_register+0x57/0x111
[ 9.306342]
[ 9.306343] stack backtrace:
[ 9.307729] Pid: 1, comm: swapper Not tainted 2.6.34-rc3-mmotm0405 #2
[ 9.308447] Call Trace:
[ 9.309170] [<ffffffff810638c5>] lockdep_rcu_dereference+0xaa/0xb2
[ 9.309935] [<ffffffff81484301>] nf_log_register+0xde/0x111
[ 9.310688] [<ffffffff81b6064b>] ? log_tg_init+0x0/0x29
[ 9.311465] [<ffffffff81b60670>] log_tg_init+0x25/0x29
[ 9.312233] [<ffffffff810001ef>] do_one_initcall+0x59/0x14e
[ 9.313030] [<ffffffff81b3268a>] kernel_init+0x144/0x1ce
[ 9.313819] [<ffffffff81003514>] kernel_thread_helper+0x4/0x10
[ 9.314625] [<ffffffff8159cb80>] ? restore_args+0x0/0x30
[ 9.315434] [<ffffffff81b32546>] ? kernel_init+0x0/0x1ce
[ 9.316224] [<ffffffff81003510>] ? kernel_thread_helper+0x0/0x10
[ 9.317037] TCP bic registeredQuoted 6 lines · [email protected] wrote:
Quoted 5 lines · Patrick McHardy
Quoted 5 lines
[ 11.488579] =================================================== [ 11.489529] [ INFO: suspicious rcu_dereference_check() usage. ] [ 11.489988] --------------------------------------------------- [ 11.490494] net/netfilter/nf_conntrack_ecache.c:88 invoked rcu_dereference_check() without protection! [ 11.491024]
Quoted 8 lines
Quoted 4 lines
There are some unnecessary
rcu_dereference()calls in the conntrack notifier registration and unregistration functions.Does this fix it?
Well, it *changed* it. Does the
rcu_defererence_check()only fire on the first time it hits something, so we've fixed the first one and now we get to see the second one?
It appears that way, otherwise you should have seen a second warning in nf_conntrack_ecache the last time.
Quoted 2 lines
(For what it's worth, if this is going to be one-at-a-time whack-a-mole, I'm OK on that, just want to know up front.)
I went through the other files and I believe this should be it. We already removed most of these incorrect rcu_dereference() calls a while back.
Quoted 7 lines
[ 9.299425] ip_tables: (C) 2000-2006 Netfilter Core Team [ 9.299486] [ 9.299486] =================================================== [ 9.300499] [ INFO: suspicious rcu_dereference_check() usage. ] [ 9.301001] --------------------------------------------------- [ 9.301523] net/netfilter/nf_log.c:55 invoked rcu_dereference_check() without protection! [ 9.302066]
net/netfilter/nf_conntrack_ecache.c +4 -14
@@ -81,11 +81,9 @@ EXPORT_SYMBOL_GPL(nf_ct_deliver_cached_events);int nf_conntrack_register_notifier (struct nf_ct_event_notifier *new) {int ret =0 ; -struct nf_ct_event_notifier *notify;mutex_lock (&nf_ct_ecache_mutex); - notify =rcu_dereference (nf_conntrack_event_cb); -if (notify !=NULL ) { +if (nf_conntrack_event_cb !=NULL ) { ret = -EBUSY ; goto out_unlock; }
@@ -101,11 +99,8 @@ EXPORT_SYMBOL_GPL(nf_conntrack_register_notifier);void nf_conntrack_unregister_notifier (struct nf_ct_event_notifier *new) { -struct nf_ct_event_notifier *notify; -mutex_lock (&nf_ct_ecache_mutex); - notify =rcu_dereference (nf_conntrack_event_cb); -BUG_ON (notify != new); +BUG_ON (nf_conntrack_event_cb != new);rcu_assign_pointer (nf_conntrack_event_cb,NULL );mutex_unlock (&nf_ct_ecache_mutex); }
@@ -114,11 +109,9 @@ EXPORT_SYMBOL_GPL(nf_conntrack_unregister_notifier);int nf_ct_expect_register_notifier (struct nf_exp_event_notifier *new) {int ret =0 ; -struct nf_exp_event_notifier *notify;mutex_lock (&nf_ct_ecache_mutex); - notify =rcu_dereference (nf_expect_event_cb); -if (notify !=NULL ) { +if (nf_expect_event_cb !=NULL ) { ret = -EBUSY ; goto out_unlock; }
@@ -134,11 +127,8 @@ EXPORT_SYMBOL_GPL(nf_ct_expect_register_notifier);void nf_ct_expect_unregister_notifier (struct nf_exp_event_notifier *new) { -struct nf_exp_event_notifier *notify; -mutex_lock (&nf_ct_ecache_mutex); - notify =rcu_dereference (nf_expect_event_cb); -BUG_ON (notify != new); +BUG_ON (nf_expect_event_cb != new);rcu_assign_pointer (nf_expect_event_cb,NULL );mutex_unlock (&nf_ct_ecache_mutex); }
net/netfilter/nf_log.c +2 -6
@@ -35,7 +35,6 @@ static struct nf_logger *__find_logger(int pf, const char *str_logger)/* return EEXIST if the same logger is registred, 0 on success. */ int nf_log_register (u_int8_t pf,struct nf_logger *logger) { -const struct nf_logger *llog;int i;if (pf >=ARRAY_SIZE (nf_loggers))
@@ -52,8 +51,7 @@ int nf_log_register(u_int8_t pf, struct nf_logger *logger) }else {/* register at end of list to honor first register win */ list_add_tail (&logger->list[pf], &nf_loggers_l[pf]); - llog =rcu_dereference (nf_loggers[pf]); -if (llog ==NULL ) +if (nf_loggers[pf] ==NULL )rcu_assign_pointer (nf_loggers[pf], logger); }
@@ -65,13 +63,11 @@ EXPORT_SYMBOL(nf_log_register);void nf_log_unregister (struct nf_logger *logger) { -const struct nf_logger *c_logger;int i;mutex_lock (&nf_log_mutex);for (i =0 ; i <ARRAY_SIZE (nf_loggers); i++) { - c_logger =rcu_dereference (nf_loggers[i]); -if (c_logger == logger) +if (nf_loggers[i] == logger)rcu_assign_pointer (nf_loggers[i],NULL );list_del (&logger->list[i]); }
Quoted 9 lines · Patrick McHardy
Quoted 3 lines · [email protected] wrote:
Well, it *changed* it. Does the
rcu_defererence_check()only fire on the first time it hits something, so we've fixed the first one and now we get to see the second one?It appears that way, otherwise you should have seen a second warning in
nf_conntrack_ecachethe last time.
Quoted 6 lines
Quoted 2 lines
(For what it's worth, if this is going to be one-at-a-time whack-a-mole, I'm OK on that, just want to know up front.)
I went through the other files and I believe this should be it. We already removed most of these incorrect
rcu_dereference()calls a while back.
Confirming - the second version of the patch fixes all the network-related RCU complaints I've been able to trigger...
Patrick McHardy
Tested-by Valdis KletnieksQuoted 10 lines · [email protected] wrote:
Quoted 8 lines · Patrick McHardy
Quoted 3 lines · [email protected] wrote:
Well, it *changed* it. Does the
rcu_defererence_check()only fire on the first time it hits something, so we've fixed the first one and now we get to see the second one?It appears that way, otherwise you should have seen a second warning in
nf_conntrack_ecachethe last time.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
(For what it's worth, if this is going to be one-at-a-time whack-a-mole, I'm OK on that, just want to know up front.)
I went through the other files and I believe this should be it. We already removed most of these incorrect
rcu_dereference()calls a while back.Confirming - the second version of the patch fixes all the network-related RCU complaints I've been able to trigger...
Thanks. I've added the attached commit to the nf-next tree. I'll push it to Dave shortly so this can get included in the next tree.
Quoted 1 line
From
ed86308f6179d8fa6151c2d0f652aad0091548e2Mon Sep 17 00:00:00 2001
From: Patrick McHardy <[email protected]>
Date: Fri, 9 Apr 2010 16:42:15 +0200
Subject: [PATCH] netfilter: remove invalid rcu_dereference() calls
The CONFIG_PROVE_RCU option discovered a few invalid uses of rcu_dereference() in netfilter. In all these cases, the code code intends to check whether a pointer is already assigned when performing registration or whether the assigned pointer matches when performing unregistration. The entire registration/ unregistration is protected by a mutex, so we don't need the rcu_dereference() calls.
--- net/netfilter/nf_conntrack_ecache.c | 18 ++++-------------- net/netfilter/nf_log.c | 8 ++------ 2 files changed, 6 insertions(+), 20 deletions(-)
net/netfilter/nf_conntrack_ecache.c +4 -14
@@ -81,11 +81,9 @@ EXPORT_SYMBOL_GPL(nf_ct_deliver_cached_events);int nf_conntrack_register_notifier (struct nf_ct_event_notifier *new) {int ret =0 ; -struct nf_ct_event_notifier *notify;mutex_lock (&nf_ct_ecache_mutex); - notify =rcu_dereference (nf_conntrack_event_cb); -if (notify !=NULL ) { +if (nf_conntrack_event_cb !=NULL ) { ret = -EBUSY ; goto out_unlock; }
@@ -101,11 +99,8 @@ EXPORT_SYMBOL_GPL(nf_conntrack_register_notifier);void nf_conntrack_unregister_notifier (struct nf_ct_event_notifier *new) { -struct nf_ct_event_notifier *notify; -mutex_lock (&nf_ct_ecache_mutex); - notify =rcu_dereference (nf_conntrack_event_cb); -BUG_ON (notify != new); +BUG_ON (nf_conntrack_event_cb != new);rcu_assign_pointer (nf_conntrack_event_cb,NULL );mutex_unlock (&nf_ct_ecache_mutex); }
@@ -114,11 +109,9 @@ EXPORT_SYMBOL_GPL(nf_conntrack_unregister_notifier);int nf_ct_expect_register_notifier (struct nf_exp_event_notifier *new) {int ret =0 ; -struct nf_exp_event_notifier *notify;mutex_lock (&nf_ct_ecache_mutex); - notify =rcu_dereference (nf_expect_event_cb); -if (notify !=NULL ) { +if (nf_expect_event_cb !=NULL ) { ret = -EBUSY ; goto out_unlock; }
@@ -134,11 +127,8 @@ EXPORT_SYMBOL_GPL(nf_ct_expect_register_notifier);void nf_ct_expect_unregister_notifier (struct nf_exp_event_notifier *new) { -struct nf_exp_event_notifier *notify; -mutex_lock (&nf_ct_ecache_mutex); - notify =rcu_dereference (nf_expect_event_cb); -BUG_ON (notify != new); +BUG_ON (nf_expect_event_cb != new);rcu_assign_pointer (nf_expect_event_cb,NULL );mutex_unlock (&nf_ct_ecache_mutex); }
net/netfilter/nf_log.c +2 -6
@@ -35,7 +35,6 @@ static struct nf_logger *__find_logger(int pf, const char *str_logger)/* return EEXIST if the same logger is registred, 0 on success. */ int nf_log_register (u_int8_t pf,struct nf_logger *logger) { -const struct nf_logger *llog;int i;if (pf >=ARRAY_SIZE (nf_loggers))
@@ -52,8 +51,7 @@ int nf_log_register(u_int8_t pf, struct nf_logger *logger) }else {/* register at end of list to honor first register win */ list_add_tail (&logger->list[pf], &nf_loggers_l[pf]); - llog =rcu_dereference (nf_loggers[pf]); -if (llog ==NULL ) +if (nf_loggers[pf] ==NULL )rcu_assign_pointer (nf_loggers[pf], logger); }
@@ -65,13 +63,11 @@ EXPORT_SYMBOL(nf_log_register);void nf_log_unregister (struct nf_logger *logger) { -const struct nf_logger *c_logger;int i;mutex_lock (&nf_log_mutex);for (i =0 ; i <ARRAY_SIZE (nf_loggers); i++) { - c_logger =rcu_dereference (nf_loggers[i]); -if (c_logger == logger) +if (nf_loggers[i] == logger)rcu_assign_pointer (nf_loggers[i],NULL );list_del (&logger->list[i]); }
Signature · 1 line
1.7.0.4
mmotm 2010-04-05 - another RCU whinge (not network this time)
In reply to [email protected]Quoted 3 lines · On Mon, 05 Apr 2010 16:09:45 PDT, [email protected] said:
The mm-of-the-moment snapshot 2010-04-05-16-09 has been uploaded to
Hit another one. I seem to be on a roll...
Seen in dmesg, happened near end of the initrd..
[ 26.756864]
[ 26.756866] ===================================================
[ 26.756869] [ INFO: suspicious rcu_dereference_check() usage. ]
[ 26.756871] ---------------------------------------------------
[ 26.756874] fs/proc/array.c:241 invoked rcu_dereference_check() without protection!
[ 26.756876]
[ 26.756877] other info that might help us debug this:
[ 26.756877]
[ 26.756879]
[ 26.756880] rcu_scheduler_active = 1, debug_locks = 0
[ 26.756883] 2 locks held by pidof/2197:
[ 26.756884] #0: (&p->lock){+.+.+.}, at: [<ffffffff810f4c2a>] seq_read+0x3a/0x42d
[ 26.756894] #1: (&(&sighand->siglock)->rlock){......}, at: [<ffffffff81047eff>] lock_task_sighand+0x79/0xcf
[ 26.756903]
[ 26.756903] stack backtrace:
[ 26.756906] Pid: 2197, comm: pidof Not tainted 2.6.34-rc3-mmotm0405 #3
[ 26.756909] Call Trace:
[ 26.756914] [<ffffffff810638c5>] lockdep_rcu_dereference+0xaa/0xb2
[ 26.756919] [<ffffffff8112ed88>] collect_sigign_sigcatch+0x37/0xa0
[ 26.756923] [<ffffffff8112f066>] do_task_stat+0x275/0x837
[ 26.756927] [<ffffffff81063f83>] ? mark_held_locks+0x52/0x70
[ 26.756931] [<ffffffff810af6be>] ? get_page_from_freelist+0x390/0x5ab
[ 26.756935] [<ffffffff81062e7b>] ? register_lock_class+0x1e/0x325
[ 26.756938] [<ffffffff8106421a>] ? trace_hardirqs_on+0xd/0xf
[ 26.756942] [<ffffffff810af742>] ? get_page_from_freelist+0x414/0x5ab
[ 26.756946] [<ffffffff81063d32>] ? mark_lock+0x2d/0x22c
[ 26.756949] [<ffffffff81063d32>] ? mark_lock+0x2d/0x22c
[ 26.756953] [<ffffffff81064fe7>] ? __lock_acquire+0x391/0xcfc
[ 26.756956] [<ffffffff810b006f>] ? __alloc_pages_nodemask+0x796/0x823
[ 26.756961] [<ffffffff810d4e60>] ? ____cache_alloc+0x10a/0x5cb
[ 26.756964] [<ffffffff810d4e60>] ? ____cache_alloc+0x10a/0x5cb
[ 26.756969] [<ffffffff8159f84c>] ? sub_preempt_count+0x35/0x49
[ 26.756973] [<ffffffff8112f637>] proc_tgid_stat+0xf/0x11
[ 26.756977] [<ffffffff8112c005>] proc_single_show+0x57/0x74
[ 26.756980] [<ffffffff810f4ca1>] ? seq_read+0xb1/0x42d
[ 26.756983] [<ffffffff810f4dc3>] seq_read+0x1d3/0x42d
[ 26.756988] [<ffffffff810da357>] vfs_read+0xe0/0x140
[ 26.756991] [<ffffffff810da46d>] sys_read+0x45/0x69
[ 26.756996] [<ffffffff810026eb>] system_call_fastpath+0x16/0x1b
[ 26.788544] dracut: Switching rootRe: mmotm 2010-04-05 - another RCU whinge (not network this time)
Quoted 7 lines · On Thu, Apr 08, 2010 at 07:57:28PM -0400, [email protected] wrote:
Quoted 3 lines · On Mon, 05 Apr 2010 16:09:45 PDT, [email protected] said:
The mm-of-the-moment snapshot 2010-04-05-16-09 has been uploaded to
Hit another one. I seem to be on a roll...
Quoted 7 lines
Seen in dmesg, happened near end of the initrd..
[ 26.756864] [ 26.756866] =================================================== [ 26.756869] [ INFO: suspicious rcu_dereference_check() usage. ] [ 26.756871] --------------------------------------------------- [ 26.756874] fs/proc/array.c:241 invoked rcu_dereference_check() without protection!
Color me confused. I cloned James Toy's git repository atgit://zen-kernel.org/kernel/mmotm.git, and gitk claims that I am on tag 2010-04-05-16-09, which matches the string above. But when I look at fs/proc/array.c near line 241, I see:
238 static void collect_sigign_sigcatch(struct task_struct *p, sigset_t *ign,
239 sigset_t *catch)
240 {
241 struct k_sigaction *k;
242 int i;
243
244 k = p->sighand->action;
245 for (i = 1; i <= _NSIG; ++i, ++k) {
246 if (k->sa.sa_handler == SIG_IGN)
247 sigaddset(ign, i);
248 else if (k->sa.sa_handler != SIG_DFL)
249 sigaddset(catch, i);
250 }
251 }
It seems unlikely that line 241 generated the above error.
Am I on the wrong version? Or do the git tags not mean what I think that they mean?
Thanx, Paul
Quoted 36 lines
[ 26.756876]
[ 26.756877] other info that might help us debug this:
[ 26.756877]
[ 26.756879]
[ 26.756880] rcu_scheduler_active = 1, debug_locks = 0
[ 26.756883] 2 locks held by pidof/2197:
[ 26.756884] #0: (&p->lock){+.+.+.}, at: [<ffffffff810f4c2a>] seq_read+0x3a/0x42d
[ 26.756894] #1: (&(&sighand->siglock)->rlock){......}, at: [<ffffffff81047eff>] lock_task_sighand+0x79/0xcf
[ 26.756903]
[ 26.756903] stack backtrace:
[ 26.756906] Pid: 2197, comm: pidof Not tainted 2.6.34-rc3-mmotm0405 #3
[ 26.756909] Call Trace:
[ 26.756914] [<ffffffff810638c5>] lockdep_rcu_dereference+0xaa/0xb2
[ 26.756919] [<ffffffff8112ed88>] collect_sigign_sigcatch+0x37/0xa0
[ 26.756923] [<ffffffff8112f066>] do_task_stat+0x275/0x837
[ 26.756927] [<ffffffff81063f83>] ? mark_held_locks+0x52/0x70
[ 26.756931] [<ffffffff810af6be>] ? get_page_from_freelist+0x390/0x5ab
[ 26.756935] [<ffffffff81062e7b>] ? register_lock_class+0x1e/0x325
[ 26.756938] [<ffffffff8106421a>] ? trace_hardirqs_on+0xd/0xf
[ 26.756942] [<ffffffff810af742>] ? get_page_from_freelist+0x414/0x5ab
[ 26.756946] [<ffffffff81063d32>] ? mark_lock+0x2d/0x22c
[ 26.756949] [<ffffffff81063d32>] ? mark_lock+0x2d/0x22c
[ 26.756953] [<ffffffff81064fe7>] ? __lock_acquire+0x391/0xcfc
[ 26.756956] [<ffffffff810b006f>] ? __alloc_pages_nodemask+0x796/0x823
[ 26.756961] [<ffffffff810d4e60>] ? ____cache_alloc+0x10a/0x5cb
[ 26.756964] [<ffffffff810d4e60>] ? ____cache_alloc+0x10a/0x5cb
[ 26.756969] [<ffffffff8159f84c>] ? sub_preempt_count+0x35/0x49
[ 26.756973] [<ffffffff8112f637>] proc_tgid_stat+0xf/0x11
[ 26.756977] [<ffffffff8112c005>] proc_single_show+0x57/0x74
[ 26.756980] [<ffffffff810f4ca1>] ? seq_read+0xb1/0x42d
[ 26.756983] [<ffffffff810f4dc3>] seq_read+0x1d3/0x42d
[ 26.756988] [<ffffffff810da357>] vfs_read+0xe0/0x140
[ 26.756991] [<ffffffff810da46d>] sys_read+0x45/0x69
[ 26.756996] [<ffffffff810026eb>] system_call_fastpath+0x16/0x1b
[ 26.788544] dracut: Switching rootRe: mmotm 2010-04-05 - another RCU whinge (not network this time)
Quoted 16 lines · Paul E. McKenney
Quoted 7 lines · On Thu, Apr 08, 2010 at 07:57:28PM -0400, [email protected] wrote:
Quoted 3 lines · On Mon, 05 Apr 2010 16:09:45 PDT, [email protected] said:
The mm-of-the-moment snapshot 2010-04-05-16-09 has been uploaded to
Hit another one. I seem to be on a roll...
Quoted 7 lines
Seen in dmesg, happened near end of the initrd..
[ 26.756864] [ 26.756866] =================================================== [ 26.756869] [ INFO: suspicious rcu_dereference_check() usage. ] [ 26.756871] --------------------------------------------------- [ 26.756874] fs/proc/array.c:241 invoked rcu_dereference_check() without protection!
Quoted 4 lines
Color me confused. I cloned James Toy's git repository at
git://zen-kernel.org/kernel/mmotm.git, and gitk claims that I am on tag 2010-04-05-16-09, which matches the string above. But when I look atfs/proc/array.cnear line 241, I see:
Andrew's -mm tree has 3 patches from Oleg Nesterov that hit that file, so the code is different from what you show. Color *me* confused why your clone of mmotm.git doesn't seem to contain them - I'm not sure how James Toy builds that git tree. Perhaps the tag is applied before those patches are - the 'mm.patch' that updates the Makefile with the version is usually in the *middle* of the 'series' file. What does HEAD of that tree look like?
My tree has:
/* needs ->siglock or rcu_read_lock() */
static void collect_sigign_sigcatch(struct task_struct *p, sigset_t *ign,
sigset_t *catch)
{
struct sighand_struct *sighand = rcu_dereference(p->sighand);And that rcu_dereference() does it.
Oleg, looks like proc-make-collect_sigign_sigcatch-rcu-safe.patch is the offender here, it added the line that causes the whinge.
Re: mmotm 2010-04-05 - another RCU whinge (not network this time)
Quoted 22 lines · On Fri, Apr 09, 2010 at 11:22:32PM -0400, [email protected] wrote:
Quoted 16 lines · Paul E. McKenney
Quoted 7 lines · On Thu, Apr 08, 2010 at 07:57:28PM -0400, [email protected] wrote:
Quoted 3 lines · On Mon, 05 Apr 2010 16:09:45 PDT, [email protected] said:
The mm-of-the-moment snapshot 2010-04-05-16-09 has been uploaded to
Hit another one. I seem to be on a roll...
Quoted 7 lines
Seen in dmesg, happened near end of the initrd..
[ 26.756864] [ 26.756866] =================================================== [ 26.756869] [ INFO: suspicious rcu_dereference_check() usage. ] [ 26.756871] --------------------------------------------------- [ 26.756874] fs/proc/array.c:241 invoked rcu_dereference_check() without protection!Quoted 4 lines
Color me confused. I cloned James Toy's git repository at
git://zen-kernel.org/kernel/mmotm.git, and gitk claims that I am on tag 2010-04-05-16-09, which matches the string above. But when I look atfs/proc/array.cnear line 241, I see:
Quoted 6 lines
Andrew's -mm tree has 3 patches from Oleg Nesterov that hit that file, so the code is different from what you show. Color *me* confused why your clone of mmotm.git doesn't seem to contain them - I'm not sure how James Toy builds that git tree. Perhaps the tag is applied before those patches are - the 'mm.patch' that updates the
Makefilewith the version is usually in the *middle* of the 'series' file. What does HEAD of that tree look like?
Good point... The last commit is branch "master" and tagged 2010-04-05-16-09, but the commit line is "Linux 2.6.34-rc3", which seems unlikely to me.
Quoted 9 lines
My tree has:
/* needs ->siglock or
rcu_read_lock()*/
static void collect_sigign_sigcatch(structtask_struct*p,sigset_t*ign,
sigset_t*catch){ struct sighand_struct *sighand = rcu_dereference(p->sighand);And that
rcu_dereference()does it.
Thank you!!!
Quoted 2 lines
Oleg, looks like proc-make-collect_sigign_sigcatch-rcu-safe.patch is the offender here, it added the line that causes the whinge.
If collect_sigign_sigcatch() is OK to call by updaters as well as readers, we need something like:
struct sighand_struct *sighand; sighand = rcu_dereference_check(p->sighand, rcu_read_lock_held() || lockdep_is_held(&???));
Where the "???" is replaced with whichever of the two locks is protecting updates. My guess would be the sighand lock, but I would not rely on my guesses in this case. ;-)
Thanx, Paul
Re: mmotm 2010-04-05 - another RCU whinge (not network this time)
Quoted 13 lines · Paul E. McKenney
Quoted 3 lines
Oleg, looks like proc-make-collect_sigign_sigcatch-rcu-safe.patch is the offender here, it added the line that causes the whinge.
If
collect_sigign_sigcatch()is OK to call by updaters as well as readers, we need something like:struct sighand_struct *sighand; sighand = rcu_dereference_check(p->sighand, rcu_read_lock_held() || lockdep_is_held(&???));
Quoted 3 lines
Where the "???" is replaced with whichever of the two locks is protecting updates. My guess would be the sighand lock, but I would not rely on my guesses in this case. ;-)
Yes, it should be p->sighand->siglock.
Actually, I was going to change another caller, do_task_stat(), to call collect_sigign_sigcatch() without ->siglock too, but now I am not sure when/if this will happen.
OK, thanks, I'll send the patch to make rcu_dereference_check() happy.
While we are here... __exit_signal() does
sighand = rcu_dereference_check(tsk->sighand, rcu_read_lock_held() || lockdep_tasklist_lock_is_held());
What is the point? We know that the single caller must hold tasklist, otherwise everything is broken. Perhaps it would be better to use rcu_dereference_raw() ?
In fact, I don't really understand why __exit_signal() needs rcu_dereference() at all.
Oleg.