[GIT PULL] Driver core update for 4.7-rc1

[Greg KH]

The following changes since commit c3b46c73264b03000d1e18b22f5caf63332547c9:

Linux 4.6-rc4 (2016-04-17 19:13:32 -0700)

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/ tags/driver-core-4.7-rc1

for you to fetch changes up to c6e360a0d9d282e9c8688dcdabdc3669912b66ef:

Revert "base: dd: don't remove driver_data in -EPROBE_DEFER case" (2016-05-03 08:06:06 -0700)

----------------------------------------------------------------
driver core update for 4.7-rc1

Here's the "big" driver core update for 4.7-rc1.

Mostly just debugfs changes, the long-known and messy races with removing
debugfs files should be fixed thanks to the great work of Nicolai Stange. We
also have some isa updates in here (the x86 maintainers told me to take it
through this tree), a new warning when we run out of dynamic char major
numbers, and a few other assorted changes, details in the shortlog.

All have been in linux-next for some time with no reported issues.

Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

----------------------------------------------------------------
Arnd Bergmann (1):
driver-core: use 'dev' argument in dev_dbg_ratelimited stub

Aviya Erenfeld (1):
devcoredump: add scatterlist support

Chris Wilson (1):
kernfs: Move faulting copy_user operations outside of the mutex

Deepa Dinamani (2):
fs: debugfs: Replace CURRENT_TIME by current_fs_time()
fs: kernfs: Replace CURRENT_TIME by current_fs_time()

Gabriel Somlo (1):
firmware: fw_cfg register offsets on supported architectures only

Greg Kroah-Hartman (2):
Merge 4.6-rc4 into driver-core-next
Revert "base: dd: don't remove driver_data in -EPROBE_DEFER case"

Linus Walleij (2):
chrdev: emit a warning when we go below dynamic major range
Documentation: update the devices.txt documentation

Nicolai Stange (8):
debugfs: prevent access to possibly dead file_operations at file open
debugfs: prevent access to removed files' private data
debugfs: add support for self-protecting attribute file fops
debugfs, coccinelle: check for obsolete DEFINE_SIMPLE_ATTRIBUTE() usage
debugfs: unproxify integer attribute files
debugfs: unproxify files created through debugfs_create_bool()
debugfs: unproxify files created through debugfs_create_blob()
debugfs: unproxify files created through debugfs_create_u32_array()

Roman Pen (1):
debugfs: fix inode i_nlink references for automount dentry

William Breathitt Gray (13):
base: isa: Remove X86_32 dependency
isa: Decouple X86_32 dependency from the ISA Kconfig option
pnp: pnpbios: Add explicit X86_32 dependency to PNPBIOS
isa: Implement the module_isa_driver macro
isa: Implement the max_num_isa_dev macro
Documentation: Add ISA bus driver documentation
iio: stx104: Add X86 dependency to STX104 Kconfig option
iio: stx104: Utilize the module_isa_driver and max_num_isa_dev macros
watchdog: ebc-c384_wdt: Utilize the ISA bus driver
gpio: 104-dio-48e: Utilize the ISA bus driver
gpio: 104-idi-48: Utilize the ISA bus driver
gpio: 104-idio-16: Utilize the ISA bus driver
gpio: ws16c48: Utilize the ISA bus driver

Yi Zhang (1):
base: dd: don't remove driver_data in -EPROBE_DEFER case

CREDITS | 1 +
Documentation/devices.txt | 86 ++--
Documentation/isa.txt | 121 ++++++
MAINTAINERS | 7 +
arch/x86/Kconfig | 4 +-
drivers/base/devcoredump.c | 83 +++-
drivers/firmware/qemu_fw_cfg.c | 4 +-
drivers/gpio/Kconfig | 38 +-
drivers/gpio/gpio-104-dio-48e.c | 106 ++---
drivers/gpio/gpio-104-idi-48.c | 86 ++--
drivers/gpio/gpio-104-idio-16.c | 85 ++--
drivers/gpio/gpio-ws16c48.c | 88 ++---
drivers/iio/dac/Kconfig | 2 +-
drivers/iio/dac/stx104.c | 24 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c | 4 +-
drivers/pnp/pnpbios/Kconfig | 2 +-
drivers/watchdog/Kconfig | 2 +-
drivers/watchdog/ebc-c384_wdt.c | 43 +-
fs/char_dev.c | 4 +
fs/debugfs/file.c | 436 +++++++++++++++++----
fs/debugfs/inode.c | 108 ++++-
fs/debugfs/internal.h | 26 ++
fs/kernfs/dir.c | 8 +-
fs/kernfs/file.c | 51 +--
fs/kernfs/inode.c | 15 +-
include/linux/debugfs.h | 49 ++-
include/linux/devcoredump.h | 86 +++-
include/linux/device.h | 7 +-
include/linux/fs.h | 2 +
include/linux/isa.h | 32 ++
include/linux/kernfs.h | 1 +
lib/Kconfig.debug | 1 +
.../api/debugfs/debugfs_simple_attr.cocci | 67 ++++
33 files changed, 1160 insertions(+), 519 deletions(-)
create mode 100644 Documentation/isa.txt
create mode 100644 fs/debugfs/internal.h
create mode 100644 scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci

[Linus Torvalds]

On Fri, May 20, 2016 at 8:23 PM, Greg KH <gre...@linuxfoundation.org> wrote:
>
> William Breathitt Gray (13):
> base: isa: Remove X86_32 dependency
> isa: Decouple X86_32 dependency from the ISA Kconfig option

So I'm going to revert these unless I get

(a) a good reason for them

(b) patches to get rid of the incessant warnings these cause.

Most of the ISA drivers are not 64-bit safe. They give compiler
warnings, and they will definitely simply not work. So just blindly
enabling that shit is not the answer.

We've never needed this before, why do we need it now?

Linus

[Greg KH]

On Fri, May 20, 2016 at 09:51:18PM -0700, Linus Torvalds wrote:
> On Fri, May 20, 2016 at 8:23 PM, Greg KH <gre...@linuxfoundation.org> wrote:
> >
> > William Breathitt Gray (13):
> > base: isa: Remove X86_32 dependency
> > isa: Decouple X86_32 dependency from the ISA Kconfig option
>
> So I'm going to revert these unless I get
>
> (a) a good reason for them
>
> (b) patches to get rid of the incessant warnings these cause.

What warnings? I haven't seen any reports of warnings, what .config
causes them?

> Most of the ISA drivers are not 64-bit safe. They give compiler
> warnings, and they will definitely simply not work. So just blindly
> enabling that shit is not the answer.
>
> We've never needed this before, why do we need it now?

I'll let William answer that, it seems he has some crazy isa hardware
for x86_64 platforms...

thanks,

greg k-h

[Linus Torvalds]

On Fri, May 20, 2016 at 10:04 PM, Greg KH <gre...@linuxfoundation.org> wrote:
>
> What warnings? I haven't seen any reports of warnings, what .config
> causes them?

There's tons of them if you just do an allmodconfig build.

This suddenly enables a lot of random 16-bit ISA driver crap on
x86-64, and not surprisingly it doesn't build cleanly, nor can most of
those drivers work.

I'll just put a smattering of the warnings at the bottom, it scrolls
off the screen.

These really are drivers that should not have been enabled. They are
legacy crap, it's not worth anybodys time to try to "fix" them, they
just shouldn't be on.

Linus

---

drivers/ide/ht6560b.c: In function ‘ht6560b_init_dev’:
drivers/ide/ht6560b.c:317:27: warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]
ide_set_drivedata(drive, (void *)t);
^
drivers/ide/qd65xx.c: In function ‘qd6500_init_dev’:
drivers/ide/qd65xx.c:295:27: warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]
ide_set_drivedata(drive, (void *)QD6500_DEF_DATA);
^
drivers/ide/qd65xx.c: In function ‘qd6580_init_dev’:
drivers/ide/qd65xx.c:311:27: warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]
ide_set_drivedata(drive, (void *)((drive->dn & 1) ? t2 : t1));
^
drivers/net/ethernet/3com/3c515.c: In function ‘corkscrew_start_xmit’:
drivers/net/ethernet/3com/3c515.c:1066:8: warning: cast from pointer
to integer of different size [-Wpointer-to-int-cast]
outl((int) (skb->data), ioaddr + Wn7_MasterAddr);
^
drivers/net/ethernet/amd/ni65.c: In function ‘ni65_stop_start’:
drivers/net/ethernet/amd/ni65.c:756:16: warning: cast from pointer to
integer of different size [-Wpointer-to-int-cast]
buffer[i] = (u32) isa_bus_to_virt(tmdp->u.buffer);
^
drivers/rtc/rtc-ds1685.o: warning: objtool: ds1685_rtc_poweroff()
falls through to next function ds1685_rtc_work_queue()
drivers/net/wan/sdla.c: In function ‘sdla_transmit’:
drivers/net/wan/sdla.c:714:13: warning: cast to pointer from integer
of different size [-Wint-to-pointer-cast]
pbuf = (void *)(((int) dev->mem_start) + (addr & SDLA_ADDR_MASK));
^

[Greg KH]

This is odd, I just tried this, and I don't get any error for
drivers/rtc/rtc-ds1685.c, nor any drivers/rtc/ file.

But I get the warning for drivers/ide/qd65xx.c, so that's not good.

Yeah, just revert it for now, let's not polute the build, sorry about
this.

thanks,

greg k-h

[Linus Torvalds]

On Fri, May 20, 2016 at 10:39 PM, Greg KH <gre...@linuxfoundation.org> wrote:
>
> This is odd, I just tried this, and I don't get any error for
> drivers/rtc/rtc-ds1685.c, nor any drivers/rtc/ file.

Ok, the rtc one was different - it's due to the objtool checks. Not
related to the ISA issue.

The others (the "warning: cast to pointer from integer" ones) are all
due to ISA, afaik.

I actually tried to find a picture of a Racal NI6510 card just to show
you guys what kinds of drivers we're talking about that got enabled. I
found a google books snipet from PC mag 1993 instead.

That piece of old-timey engineering sold for $239 USD, and it lost in
a benchmark to an ne2000 card. We're talking 10MB ethernet only,
because this was before people used fast ethernet, and the competition
was still often 10base2/BNC.

We're talking stone-age technology. We really don't want to enable it.

Linus

[William Breathitt Gray]

I'll submit patches to resolve these warnings and errors.

The primary reason for decoupling the x86_32 dependency from the X86 ISA
Kconfig option is to allow the ISA bus driver to be used to interface
with PC/104 devices.

Although you are correct that the ISA bus for general consumers is
essentially legacy from the pre-64-bit era, the PC/104 bus (a derivative
of the ISA bus) is ubiquitous in the embedded systems industry; new
PC/104 devices are developed and produced every day.

Despite the form factor difference, PC/104 devices appear to software as
ISA devices: you can interact with them like you would any other ISA
device, using I/O port-mapped reads and writes. This makes the existing
ISA bus driver an apt solution to interface with PC/104 devices (to
software, there is no difference between PC/104 and ISA).

The issue arises with the X86_32 dependency on the X86 ISA Kconfig
option: this dependency is not necessary because there is no hard 32-bit
dependency on the ISA bus itself; in fact, the ISA bus driver
(drivers/base/isa.c) is portable across all X86 platforms. Worse, the
X86_32 dependency puts an artifical limitation on PC/104 devices.

Many embedded systems vendors produce PC/104 compatible motherboards
running 64-bit X86 processors; this isn't the exception, it's the norm.
To use the ISA bus driver with the X86_32 dependency means preventing
support for PC/104 devices on virtually any modern PC/104 compatible
embedded system motherboard. There are real PC/104 devices out there,
from real companies and people, intended to run on real motherboards
with 64-bit X86 processors.

I'm in the process of developing drivers for a few new PC/104 devices.
For reference, there are currently four PC/104 drivers already merged:
the Apex Embedded Systems STX104 DAC driver, the ACCES 104-DIO-48E
series GPIO driver, the ACCES 104-IDI-48 series GPIO driver, and the
ACCES 104-IDIO-16 series GPIO driver.

Although not necessarily PC/104 devices, the WinSystems EBC-C384
watchdog timer driver and WinSystems WS16C48 GPIO driver communicate via
an ISA bus interface and are also expected to run on motherboards with
64-bit X86 processors.

One alternative to decoupling the X86_32 dependency from the ISA Kconfig
option would be to copy the drivers/base/isa.c code to a new
drivers/base/pc104.c file, which will serve as the PC/104 bus driver;
new PC/104 drivers intended to run on any X86 platform can use this new
bus driver. However, it doesn't seem right to maintain an identical set
of code simply to sidestep a Kconfig dependency issue.

Removing the X86_32 dependency from the X86 ISA Kconfig option results
in warnings and errors for two reasons:

1. The relevant code is meant to be 32-bit X86 specific.
- In this case, an explicit X86_32 should be added to the
Kconfig option for the relevant code.

2. The relevant code is meant to work on both 32-bit and 64-bit X86
platforms, but a 32-bit specific piece of code was overlooked.
- In this case, the code should be fixed to be portable across
X86 platforms as intended.

Regardless, in both scenarios, adding an explicit X86_32 dependency to
the relevant Kconfig options resolves the warnings and errors by
limiting the compilation to X86_32 as they have been before; thus the
status quo is maintained. However, a major benefit is gained: the ISA
bus driver may now be used to support these new PC/104 devices expected
to run with 64-bit X86 processors.

Regarding the excerpt of warnings already posted: the Kconfig for the
IDE chipsets has an X86 dependency which should explicitly be X86_32,
while the 3C515 and NI65 drivers' Kconfig dependencies should also be
adjusted since neither use the X86 ISA bus driver.

As I said before, it is my intention to submit patches to resolve the
warnings and errors which have appeared; they are currently there simply
because I mistakenly overlooked them when I performed my initial
testing.

I've logged the warnings and errors after compiling from an
allmodconfig, with and without the two commits, and performed a diff
between the two logs to get the new warnings and errors; there appears
to be less than 10 drivers involved, judging from the output, so I'll
investigate the causes and submit patches to resolve the relevant
warnings and errors.

Let me know if there is an alternative solution that would be more
suitable in order to facilitate PC/104 device support on 64-bit X86
platforms.

William Breathitt Gray

[Linus Torvalds]

On Sat, May 21, 2016 at 9:20 AM, William Breathitt Gray
<vilhel...@gmail.com> wrote:
>
> I'll submit patches to resolve these warnings and errors.

No.

I will disable that ISA config option. We're not randomly making old
drivers available on modern platforms. Really.

We're not suddenly enabling ISA on x86-64 after having successfully
gotten rid of that insane crap long long ago.

If you have *specific* dribvers that are actually relevant for some
reason, make those ones available based on other options. For example,
we've had the ISA_DMA_API config option to say "we support a subset of
ISA, even when we don't actually want to ever see actual plug-in ISA
cards".

Your patch already resulted in having to add several cases of

- depends on ISA
+ depends on X86 && ISA

because you tried to randomly widen what "ISA" meant. No. No no no.

No more "let's randomly change what ISA is". Do this enabling one
driver at a time, or not at all. I'm not at all interested in seeing
some kind of generic "we will support random shit on modern platfoms"
crap. 99% of all drivers that depend on ISA have no maintainership,
and will never get any maintainership.

Linus

[Linus Torvalds]

On Sat, May 21, 2016 at 9:31 AM, Linus Torvalds
<torv...@linux-foundation.org> wrote:
>
> We're not suddenly enabling ISA on x86-64 after having successfully
> gotten rid of that insane crap long long ago.
>
> If you have *specific* dribvers that are actually relevant for some
> reason, make those ones available based on other options. For example,
> we've had the ISA_DMA_API config option to say "we support a subset of
> ISA, even when we don't actually want to ever see actual plug-in ISA
> cards".

I am planning on committing something like the attached.

Note that anything that added "depends on ISA" because of the other
patches will now be disabled on x86-64, even if that driver wasn't
disabled before.

Added Linus Walleij and Guenther Roech to the cc because of the
drivers that I'm aware that did this.

To repeat: I'm not at all interested in enabling random old drivers on
x86-64. Any driver enablement needs to be done on a one-by-one basis,
after having actually gotten TESTING, and after having had people make
sure that we don't get tons of new warnings like we did with the
"let's just enable ISA randomly" approach.

I'm ok with enabling some "ISA_BUS_API" support (like we have
ISA_DMA_API) that allows people to enable drivers one-by-one as they
are converted to a convenience function. The patch series seems to
have had that kind of approach initially.

I'd suggest doing that ISA_BUS_API config option as a *general* thing
(not arch-specific), and make it start out like

config ISA_BUS_API
def_bool ISA

which means that everybody gets it, and if ISA was enabled, it will be
enabled automatically. Then, architectures that do *not* enable ISA
itself (like x86-64), could choose to have a config option like

config ISA_BUS
bool "support ISA-style drivers on modern systems" if (x86 && EXPERT)
default y
select ISA_BUS_API

or something, which means that ISA_BUS_API would then get enabled (but
not ISA itself).

That's similar to what we do today with ISA_DMA_API, except we made
the mistake of making all the different architectures define the
ISA_DMA_API option.

It's the wholesale "enable random crap" that I will not accept. Not
even if there is then "hide the crap again when it causes warnings".
Even a driver that doesn't warn isn't necessarily useful, and I don't
want people to suddenly start seeing a lot of options for random ISA
drivers that simply aren't relevant, and never will be. Not even if
they compile cleanly.

Linus

[William Breathitt Gray]

On Sat, May 21, 2016 at 09:59:09AM -0700, Linus Torvalds wrote:
>Author: Linus Torvalds <torv...@linux-foundation.org>
>Date: Sat May 21 09:13:41 2016 -0700
>
> x86 isa: add back X86_32 dependency on CONFIG_ISA
>
> Commit b3c1be1b789c ("base: isa: Remove X86_32 dependency") made ISA
> support available on x86-64 too. That's not right - while there are
> some LPC-style devices that might be useful still and be based on
> ISA-like IP blocks, that is *not* an excuse to try to enable any random
> legacy drivers.
>
> Such drivers should be individually enabled and made to perhaps depend
> on ISA_DMA_API instead (which we have continued to support on x86-64).
> Or we could add another "ISA_XYZ_API" that we support that doesn't
> enable random old drivers that aren't even 64-bit clean nor do we have
> any test coverage for.
>
> Turning off ISA will now also turn off some drivers that have been
> marked as depending on it as part of this series, and that used to work
> on modern platforms.
>
> See for example commits ad7afc38eab3..cc736607c86d, which may also need
> to be reverted.
>
> Cc: William Breathitt Gray <vilhel...@gmail.com>
> Cc: Linus Walleij <linus....@linaro.org>
> Cc: Guenter Roeck <li...@roeck-us.net>
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> Signed-off-by: Linus Torvalds <torv...@linux-foundation.org>
>
>diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>index 48ac29034e1e..0a7b885964ba 100644
>--- a/arch/x86/Kconfig
>+++ b/arch/x86/Kconfig
>@@ -2447,6 +2447,8 @@ config ISA_DMA_API
> Enables ISA-style DMA support for devices requiring such controllers.
> If unsure, say Y.
>
>+if X86_32
>+
> config ISA
> bool "ISA support"
> ---help---
>@@ -2456,8 +2458,6 @@ config ISA
> (MCA) or VESA. ISA is an older system, now being displaced by PCI;
> newer boards don't support it. If you have ISA, say Y, otherwise N.
>
>-if X86_32
>-
> config EISA
> bool "EISA support"
> depends on ISA

Acked-by: William Breathitt Gray <vilhel...@gmail.com>

That makes sense to me. The drivers which switched to use the ISA bus
driver would simply need their respective Kconfig option adjusted to
depend on a "ISA_BUS_API" option, rather than ISA, to allow them to
compile on X86_64.

Would you like me to submit a patchset after your commit to introduce
the ISA_BUS/ISA_BUS_API Kconfig options, as well as adjust the relevant
drivers' Kconfig options to depend on the ISA_BUS_API?

William Breathitt Gray

[Linus Torvalds]

On Sat, May 21, 2016 at 10:16 AM, William Breathitt Gray
<vilhel...@gmail.com> wrote:
>
> Would you like me to submit a patchset after your commit to introduce
> the ISA_BUS/ISA_BUS_API Kconfig options, as well as adjust the relevant
> drivers' Kconfig options to depend on the ISA_BUS_API?

Yes please.

Linus