* Re: [GIT PATCH] driver core patches for 3.5-rc1 - try 2
@ 2012-05-22 22:01 Joe Perches
0 siblings, 0 replies; 5+ messages in thread
From: Joe Perches @ 2012-05-22 22:01 UTC (permalink / raw)
To: Greg KH, Kay Sievers; +Cc: Linus Torvalds, Andrew Morton, linux-kernel
(resending cc'ing lkml)
(Also, apologies about no in-reply-to, lkml.org is down)
While there are several things I like about the
printk modifications, (binary header, delta time,
slightly better partial message deinterleaving,
global msg_id, kmsg is ok too), I am concerned
about the utility and expectations for the new
[v]printk_emit functions.
I think it is not really ready to be merged
at this time.
The commit sequencing was unclean.
The original commit originally required KERN_CONT
and it was modified by another commit to return
to the current behavior.
What really are the expectations and true use-cases
for [v]printk_emit?
How is it really better that what is available now?
Perhaps it would be better to respin all the
printk modifications without adding [v]printk_emit
and have the [v]printk_emit bits debated a bit more.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [GIT PATCH] driver core patches for 3.5-rc1 - try 2
2012-05-22 22:12 ` Joe Perches
@ 2012-05-23 6:12 ` Greg KH
0 siblings, 0 replies; 5+ messages in thread
From: Greg KH @ 2012-05-23 6:12 UTC (permalink / raw)
To: Joe Perches; +Cc: Kay Sievers, Linus Torvalds, Andrew Morton, linux-kernel
On Tue, May 22, 2012 at 03:12:16PM -0700, Joe Perches wrote:
> On Tue, 2012-05-22 at 15:05 -0700, Greg KH wrote:
> > On Tue, May 22, 2012 at 02:58:47PM -0700, Joe Perches wrote:
> > > How is it really better that what is available now?
> > >
> > > Perhaps it would be better to respin all the
> > > printk modifications without adding [v]printk_emit
> > > and have the [v]printk_emit bits debated a bit more.
> >
> > I'm always glad to review patches, but to just propose something that
> > works to be reverted without a patch to replace the functionality, isn't
> > ok.
>
> It hasn't been committed yet in anything other than
> -next.
>
> Lots of stuff gets committed there and later removed
> and hits Linus' mainline tree.
Sorry, but as people are "downstream" for me, I do not rebase my trees,
unless something really bad happened (i.e. I messed up the tree). So
this will not happen, sorry.
Also, the patches are all in Linus's tree now, so the point is moot.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [GIT PATCH] driver core patches for 3.5-rc1 - try 2
[not found] ` <20120522220534.GC12705@kroah.com>
@ 2012-05-22 22:12 ` Joe Perches
2012-05-23 6:12 ` Greg KH
0 siblings, 1 reply; 5+ messages in thread
From: Joe Perches @ 2012-05-22 22:12 UTC (permalink / raw)
To: Greg KH; +Cc: Kay Sievers, Linus Torvalds, Andrew Morton, linux-kernel
(adding lkml and not editing Greg's reply)
On Tue, 2012-05-22 at 15:05 -0700, Greg KH wrote:
> On Tue, May 22, 2012 at 02:58:47PM -0700, Joe Perches wrote:
> > While there are several things I like about the
> > printk modifications, (binary header, delta time,
> > slightly better partial message deinterleaving,
> > global msg_id, kmsg is ok too), I am concerned
> > about the utility and expectations for the new
> > [v]printk_emit functions.
> >
> > I think it is not really ready to be merged
> > at this time.
> >
> > The commit sequencing was unclean.
>
> Yes, but the build was never broken, the system always worked, and the
> end result was agreed apon by everyone as a nice addition.
>
> > The original commit originally required KERN_CONT
> > and it was modified by another commit to return
> > to the current behavior.
> >
> > What really are the expectations and true use-cases
> > for [v]printk_emit?
>
> What's wrong with the existing use case? Since when do we write
> use-cases for kernel functions?
When it's a generic function that appears to be used
to attach additional data to message logging,
and it takes up buffer space and currently reduces
the number of dev_<foo> messages in dmesg without
adding value.
What's it for and who's going to use it and more
importantly, why?
I do not want to link human readable messaging with
machine parsing of binary data. I'm not sure it's
useful and possibly sets expectations for immutability.
> > How is it really better that what is available now?
> >
> > Perhaps it would be better to respin all the
> > printk modifications without adding [v]printk_emit
> > and have the [v]printk_emit bits debated a bit more.
>
> I'm always glad to review patches, but to just propose something that
> works to be reverted without a patch to replace the functionality, isn't
> ok.
It hasn't been committed yet in anything other than
-next.
Lots of stuff gets committed there and later removed
and hits Linus' mainline tree.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [GIT PATCH] driver core patches for 3.5-rc1 - try 2
[not found] <1337723927.9270.15.camel@joe2Laptop>
@ 2012-05-22 22:08 ` Greg KH
[not found] ` <20120522220534.GC12705@kroah.com>
1 sibling, 0 replies; 5+ messages in thread
From: Greg KH @ 2012-05-22 22:08 UTC (permalink / raw)
To: Joe Perches; +Cc: Kay Sievers, linux-kernel, Linus Torvalds, Andrew Morton
On Tue, May 22, 2012 at 02:58:47PM -0700, Joe Perches wrote:
> While there are several things I like about the
> printk modifications, (binary header, delta time,
> slightly better partial message deinterleaving,
> global msg_id, kmsg is ok too), I am concerned
> about the utility and expectations for the new
> [v]printk_emit functions.
>
> I think it is not really ready to be merged
> at this time.
>
> The commit sequencing was unclean.
Yes, but the build was never broken, the system always worked, and the
end result was agreed apon by everyone as a nice addition.
> The original commit originally required KERN_CONT
> and it was modified by another commit to return
> to the current behavior.
>
> What really are the expectations and true use-cases
> for [v]printk_emit?
What's wrong with the existing use case? Since when do we write
use-cases for kernel functions?
> How is it really better that what is available now?
>
> Perhaps it would be better to respin all the
> printk modifications without adding [v]printk_emit
> and have the [v]printk_emit bits debated a bit more.
I'm always glad to review patches, but to just propose something that
works to be reverted without a patch to replace the functionality, isn't
ok.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 5+ messages in thread
* [GIT PATCH] driver core patches for 3.5-rc1 - try 2
@ 2012-05-22 15:14 Greg KH
0 siblings, 0 replies; 5+ messages in thread
From: Greg KH @ 2012-05-22 15:14 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton; +Cc: linux-kernel
The following changes since commit 69964ea4c7b68c9399f7977aa5b9aa6539a6a98a:
Linux 3.4-rc5 (2012-04-29 15:19:10 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/ tags/driver-core-3.5-rc1
for you to fetch changes up to 94ca629e40eb7e997be21d8065c25e4f3797b03f:
uio_pdrv_genirq: get irq through platform resource if not set otherwise (2012-05-15 08:44:58 -0700)
----------------------------------------------------------------
Driver core pull for 3.5-rc1
Here's the driver core, and other driver subsystems, pull request for
the 3.5-rc1 merge window.
Outside of a few minor driver core changes, we ended up with the
following different subsystem and core changes as well, due to
interdependancies on the driver core:
- hyperv driver updates
- drivers/memory being created and some drivers moved into it
- extcon driver subsystem created out of the old Android staging switch
driver code
- dynamic debug updates
- printk rework, and /dev/kmsg changes
All of this has been tested in the linux-next releases for a few weeks
with no reported problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----------------------------------------------------------------
Alan Stern (1):
sysfs: get rid of some lockdep false positives
Aneesh V (7):
ddr: add LPDDR2 data from JESD209-2
memory: emif: add register definitions for EMIF
memory: emif: add basic infrastructure for EMIF driver
memory: emif: handle frequency and voltage change events
memory: emif: add interrupt and temperature handling
memory: emif: add one-time settings
memory: emif: add debugfs entries for emif
Benedikt Spranger (1):
uio_pdrv_genirq: get irq through platform resource if not set otherwise
Chanwoo Choi (3):
Extcon: Notify changed state for only one cable to notifee
Extcon: add MAX8997 extcon driver
misc: MAX8997: Remove max8997-muic driver
Dan Carpenter (3):
hv: fix return type of hv_post_message()
w1: w1_ds28e04: unlock on error path in w1_f1C_write_pio()
Extcon: check for allocation failure
Dmitry Artamonow (1):
w1: fix slave driver registration error message
Donggeun Kim (1):
Extcon: support notification based on the state changes.
Greg Kroah-Hartman (4):
Revert "driver core: check start node in klist_iter_init_node"
Revert "w1: Add 1-wire slave device driver for DS28E04-100"
Merge 3.4-rc5 into driver-core-next
Revert "dynamic_debug: remove unneeded includes"
H Hartley Sweeten (3):
drivers/base/bus.c: local variables should not be exposed globally
Extcon: fix section mismatch in extcon_gpio.c
w1: w1_ds2408.c: quite sparse noise about using plaing integer as NULL pointer
Hannes Reinecke (1):
driver core: check start node in klist_iter_init_node
Hiroshi DOYU (10):
ARM: tegra20: Add Tegra Memory Controller(MC) driver
ARM: tegra30: Add Tegra Memory Controller(MC) driver
ARM: tegra20: MC: Remove unnecessary BUG*()
ARM: tegra30: MC: Remove unnecessary BUG*()
ARM: tegra20: Make MC optional in Kconfig
ARM: tegra30: Make MC optional in Kconfig
Driver Core: don't oops with unregistered driver in driver_find_device()
driver core: Add dev_*_ratelimited() family
memory: tegra{20,30}-mc: Use dev_err_ratelimited()
memory: tegra{20,30}-mc: Remove empty *_remove()
Jim Cromie (15):
dynamic_debug: replace if (verbose) pr_info with macro vpr_info
dynamic_debug: fix leading spaces in dynamic_debug.h
params: add 3rd arg to option handler callback signature
dynamic_debug: make dynamic-debug work for module initialization
dynamic_debug: deprecate ddebug_query, suggest dyndbg instead
dynamic_debug: combine parse_args callbacks together
dynamic_debug: simplify dynamic_debug_init error exit
dynamic_debug: print ram usage by ddebug tables if verbose
dynamic_debug: add modname arg to exec_query callchain
dynamic_debug: update Documentation/*, Kconfig.debug
dynamic_debug: init with early_initcall, not arch_initcall
dynamic_debug: use printk(KERN_WARNING..) in stub function
params.c: fix Smack complaint about parse_args
dynamic_debug: remove unneeded includes
params: replace printk(KERN_<LVL>...) with pr_<lvl>(...)
K. Y. Srinivasan (2):
Drivers: hv: Get rid of an unnecessary check in vmbus_prep_negotiate_resp()
Drivers: hv: util: Properly handle version negotiations.
Kay Sievers (13):
printk: convert byte-buffer to variable-length record buffer
kmsg: export printk records to the /dev/kmsg interface
driver-core: extend dev_printk() to pass structured data
kmsg: use do_div() to divide 64bit integer
parport: use KERN_CONT in printk() continuation lines
acpi: use KERN_CONT in printk() continuation lines
mm: use KERN_CONT in printk() continuation lines
kmsg - add Documentation/ABI/testing/dev-kmsg
printk - fix compilation for CONFIG_PRINTK=n
printk() - do not merge continuation lines of different threads
printk() - restore timestamp printing at console output
printk() - restore prefix/timestamp printing for multi-newline strings
printk() - isolate KERN_CONT users from ordinary complete lines
Kees Cook (1):
docs: update HOWTO for 2.6.x -> 3.x versioning
Mark Brown (4):
extcon: Add EXTCON_MECHANICAL cable type for physical presence
devres: Clarify documentation for devres_destroy()
devres: Add devres_release()
gpiolib: Convert to devres_release()
Markus Franke (2):
w1: Add 1-wire slave device driver for DS28E04-100
w1: Disable irqs during 1-wire bus operations, extend 1-wire reset pulse
Michael Davidson (1):
driver-core: fix DEVICE_INT_ATTR to use correct show/store functions
MyungJoo Ham (6):
Extcon (external connector): import Android's switch class and modify.
Extcon: support generic GPIO extcon driver
Extcon: support multiple states at a device.
Extcon: support mutually exclusive relation between cables.
Documentation/extcon: porting guide for Android kernel switch driver.
Remove "switch" class in drivers/staging/android/switch
Paul Gortmaker (1):
powerpc: fix compile fail in hugetlb cmdline parsing
Peter Korsgaard (2):
devtmpfs: fix 'the the' typo
core.c: fix 'the the' typo
Randy Dunlap (2):
driver core: fix dma-buf.c kernel-doc warnings
printk: add stub for prepend_timestamp()
Santosh Shilimkar (1):
memory: emif: Add Kconfig dependency for TI EMIF controller
Sasikantha babu (1):
sysfs: Removed dup_name entirely in sysfs_rename
Stephen Warren (1):
printk: correctly align __log_buf
Zhi Yong Wu (1):
kobject: fix the uncorrect comment
harryxiyou (1):
Fix a mistake sentence in the file 'Documentation/zh_CN/magic-number.txt'
yan (2):
drivers/base/core.c: Fix a typo in comment
lib/kobject.c : Remove redundant check in create_dir
Documentation/ABI/testing/dev-kmsg | 90 ++
Documentation/ABI/testing/sysfs-class-extcon | 97 ++
Documentation/HOWTO | 32 +-
Documentation/devices.txt | 3 +-
.../bindings/arm/tegra/nvidia,tegra20-mc.txt | 16 +
.../bindings/arm/tegra/nvidia,tegra30-mc.txt | 18 +
Documentation/dynamic-debug-howto.txt | 184 ++-
Documentation/extcon/porting-android-switch-class | 124 ++
Documentation/feature-removal-schedule.txt | 9 +-
Documentation/kernel-parameters.txt | 7 +-
Documentation/memory-devices/ti-emif.txt | 57 +
Documentation/zh_CN/magic-number.txt | 2 +-
arch/powerpc/mm/hugetlbpage.c | 3 +-
drivers/Kconfig | 4 +
drivers/Makefile | 2 +
drivers/acpi/pci_link.c | 12 +-
drivers/acpi/sleep.c | 8 +-
drivers/base/bus.c | 3 +-
drivers/base/core.c | 58 +-
drivers/base/devres.c | 35 +
drivers/base/devtmpfs.c | 6 +-
drivers/base/dma-buf.c | 12 +-
drivers/base/driver.c | 2 +-
drivers/char/mem.c | 42 +-
drivers/extcon/Kconfig | 32 +
drivers/extcon/Makefile | 7 +
.../max8997-muic.c => extcon/extcon-max8997.c} | 200 ++-
drivers/extcon/extcon_class.c | 832 ++++++++++
drivers/extcon/extcon_gpio.c | 169 ++
drivers/gpio/devres.c | 3 +-
drivers/hv/channel_mgmt.c | 73 +-
drivers/hv/hv.c | 2 +-
drivers/hv/hv_kvp.c | 3 +-
drivers/hv/hv_util.c | 9 +-
drivers/hv/hyperv_vmbus.h | 2 +-
drivers/memory/Kconfig | 43 +
drivers/memory/Makefile | 7 +
drivers/memory/emif.c | 1670 ++++++++++++++++++++
drivers/memory/emif.h | 589 +++++++
drivers/memory/tegra20-mc.c | 257 +++
drivers/memory/tegra30-mc.c | 382 +++++
drivers/misc/Kconfig | 8 -
drivers/misc/Makefile | 1 -
drivers/parport/parport_pc.c | 16 +-
drivers/staging/android/Kconfig | 3 -
drivers/staging/android/Makefile | 1 -
drivers/staging/android/switch/Kconfig | 11 -
drivers/staging/android/switch/Makefile | 4 -
drivers/staging/android/switch/switch.h | 53 -
drivers/staging/android/switch/switch_class.c | 174 --
drivers/staging/android/switch/switch_gpio.c | 172 --
drivers/uio/uio_pdrv_genirq.c | 8 +
drivers/usb/core/sysfs.c | 6 +-
drivers/w1/slaves/w1_ds2408.c | 2 -
drivers/w1/w1.c | 2 +-
drivers/w1/w1_io.c | 22 +-
fs/sysfs/dir.c | 37 +-
include/linux/device.h | 34 +-
include/linux/dynamic_debug.h | 22 +-
include/linux/extcon.h | 324 ++++
include/linux/extcon/extcon_gpio.h | 52 +
include/linux/hyperv.h | 4 +-
include/linux/mfd/max8997.h | 23 -
include/linux/moduleparam.h | 3 +-
include/linux/platform_data/emif_plat.h | 128 ++
include/linux/printk.h | 13 +
include/linux/sysfs.h | 12 +
include/memory/jedec_ddr.h | 175 ++
init/main.c | 33 +-
kernel/module.c | 2 +-
kernel/params.c | 62 +-
kernel/printk.c | 1390 +++++++++++-----
lib/Kconfig | 8 +
lib/Kconfig.debug | 33 +-
lib/Makefile | 2 +
lib/dynamic_debug.c | 190 ++-
lib/jedec_ddr_data.c | 135 ++
lib/kobject.c | 14 +-
mm/page_alloc.c | 6 +-
79 files changed, 6981 insertions(+), 1310 deletions(-)
create mode 100644 Documentation/ABI/testing/dev-kmsg
create mode 100644 Documentation/ABI/testing/sysfs-class-extcon
create mode 100644 Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-mc.txt
create mode 100644 Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-mc.txt
create mode 100644 Documentation/extcon/porting-android-switch-class
create mode 100644 Documentation/memory-devices/ti-emif.txt
create mode 100644 drivers/extcon/Kconfig
create mode 100644 drivers/extcon/Makefile
rename drivers/{misc/max8997-muic.c => extcon/extcon-max8997.c} (75%)
create mode 100644 drivers/extcon/extcon_class.c
create mode 100644 drivers/extcon/extcon_gpio.c
create mode 100644 drivers/memory/Kconfig
create mode 100644 drivers/memory/Makefile
create mode 100644 drivers/memory/emif.c
create mode 100644 drivers/memory/emif.h
create mode 100644 drivers/memory/tegra20-mc.c
create mode 100644 drivers/memory/tegra30-mc.c
delete mode 100644 drivers/staging/android/switch/Kconfig
delete mode 100644 drivers/staging/android/switch/Makefile
delete mode 100644 drivers/staging/android/switch/switch.h
delete mode 100644 drivers/staging/android/switch/switch_class.c
delete mode 100644 drivers/staging/android/switch/switch_gpio.c
create mode 100644 include/linux/extcon.h
create mode 100644 include/linux/extcon/extcon_gpio.h
create mode 100644 include/linux/platform_data/emif_plat.h
create mode 100644 include/memory/jedec_ddr.h
create mode 100644 lib/jedec_ddr_data.c
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-05-23 6:12 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-05-22 22:01 [GIT PATCH] driver core patches for 3.5-rc1 - try 2 Joe Perches
[not found] <1337723927.9270.15.camel@joe2Laptop>
2012-05-22 22:08 ` Greg KH
[not found] ` <20120522220534.GC12705@kroah.com>
2012-05-22 22:12 ` Joe Perches
2012-05-23 6:12 ` Greg KH
-- strict thread matches above, loose matches on Subject: below --
2012-05-22 15:14 Greg KH
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.