[PATCH] sparc64: Add preprocessor symbols for PAGE_* pgprot_t values.

[Clemens Ladisch]

Kernel code assumes that the PAGE_* values are preprocessor symbols, and
that therefore arch support can be checked for with #ifdef.

At the moment, sparc64 does not implement any of the symbols checked
for, so these checks happen to work.

To prevent potential breakage when another #ifdef check is added or when
sparc64 implements another PAGE_ value, make such #ifdef checks work by
adding preprocessor symbols on top of the PAGE_* variables.

Signed-off-by: Clemens Ladisch clem...@ladisch.de
---
 arch/sparc/include/asm/pgtable_64.h |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/sparc/include/asm/pgtable_64.h 
b/arch/sparc/include/asm/pgtable_64.h
index bfeb626..a835fe9 100644
--- a/arch/sparc/include/asm/pgtable_64.h
+++ b/arch/sparc/include/asm/pgtable_64.h
@@ -216,9 +216,13 @@ pte_t mk_pte_io(unsigned long, pgprot_t, int, unsigned 
long);
 unsigned long pte_sz_bits(unsigned long size);

 extern pgprot_t PAGE_KERNEL;
+#define PAGE_KERNELPAGE_KERNEL
 extern pgprot_t PAGE_KERNEL_LOCKED;
+#define PAGE_KERNEL_LOCKED PAGE_KERNEL_LOCKED
 extern pgprot_t PAGE_COPY;
+#define PAGE_COPY  PAGE_COPY
 extern pgprot_t PAGE_SHARED;
+#define PAGE_SHAREDPAGE_SHARED

 /* XXX This uglyness is for the atyfb driver's sparc mmap() support. XXX */
 extern unsigned long _PAGE_IE;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sparc64: Add preprocessor symbols for PAGE_* pgprot_t values.

[Clemens Ladisch]

David Miller wrote:
 Kernel code assumes that the PAGE_* values are preprocessor symbols, and
 that therefore arch support can be checked for with #ifdef.

 At the moment, sparc64 does not implement any of the symbols checked
 for, so these checks happen to work.

 To prevent potential breakage when another #ifdef check is added or when
 sparc64 implements another PAGE_ value, make such #ifdef checks work by
 adding preprocessor symbols on top of the PAGE_* variables.

 Signed-off-by: Clemens Ladisch clem...@ladisch.de

 This change actually doesn't have any effect, and doesn't matter,
  so let's make this change.

 I really don't buy this.

At the moment, sparc64 does not support symbols such as PAGE_KERNEL_RO,
and has no mechanism for arch-independent code to detect this.
Some code tries anyway:

$ git grep '#ifn\?def PAGE_KERNEL_'
drivers/base/firmware_class.c:#ifndef PAGE_KERNEL_RO
drivers/staging/comedi/comedi_buf.c:#ifdef PAGE_KERNEL_NOCACHE
mm/nommu.c:#ifndef PAGE_KERNEL_EXEC
mm/vmalloc.c:#ifndef PAGE_KERNEL_EXEC

I don't want to add more such code to the kernel without a guarantee
that it actually works, or without replacing it with some other kind
of check that does work.

 I'd also rather the kernel use Kconfig based symbols to detect for
 arch availability of feature X or Y, assuming things are CPP symbols
 is very fragile at best.

It is certainly possible to use Kconfig-based symbols.  However, this
would have its own fragility: adding, e.g., PAGE_KERNEL_SO to an arch
requires that one remembers to update Kconfig, and if one forgets,
a check like this:

#ifndef CONFIG_ARCH_HAS_PAGE_KERNEL_RO
#define PAGE_KERNEL_RO PAGE_KERNEL /* fallback for this code */
#endif

will not detect the error on sparc64 (if PAGE_KERNEL_RO were a CPP
symbol, the compiler would complain about the redefinition).

So even if PAGE_KERNEL_RO is a variable, making it into a CPP symbol
is beneficial.  And once it is a CPP symbol, introducing a separate
Kconfig-based symbol is not necessary and just increases the chances
of an error.


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

Re: Using kernel filesystems as userland libraries

[Clemens Ladisch]

Nicolas George wrote:
 With the libraries present in e2fsprogs, it is possible to open a plain file
 (or any other reasonable storage) as an EXT2 filesystem and manipulate files
 inside it.

 Is it possible to use the implementations in the kernel to do the same thing
 with any supported normal filesystem?

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

Re: reboot housekeeping, lack thereof, is messing with me

[Clemens Ladisch]

Gene Heskett wrote:
 To whomever is in charge of the supposedly volatile LCK.. files in
 /var/lock:

Whoever that may be, it's not the kernel.

 Its my understanding that these files should be volatile when they
 represent a USB usage, because a USB device can be unplugged instantly and
 at any time.  The device nicely and dutifully disappears from an 'ls /dev'
 listing when a device is unplugged.

 Why is it then that the /var/lock/LCK..ttyUSB1 file is always left behind,
 so it screws up any possibility of doing a nice clean reboot and restart
 of the program that uses it?

What program leaves this file behind?  (The pid in there is no longer
helpful, unless it got logged due to a segfault, but what was the last
program used for serial stuff?)

Anyway, it appears some programs automatically delete this file when the
pid is not valid.


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

[PATCH] staging/fwserial: use correct vendor/version IDs

[Clemens Ladisch]

The driver was using the vendor ID 0xd00d1e from the FireWire core.
However, this ID was not registered, and invalid.

Instead, use the vendor/version IDs that now are officially assigned to
firewire-serial:
https://ieee1394.wiki.kernel.org/index.php/IEEE_OUI_Assignments

Signed-off-by: Clemens Ladisch clem...@ladisch.de
---
 drivers/staging/fwserial/TODO   |5 ++---
 drivers/staging/fwserial/fwserial.c |4 ++--
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/fwserial/TODO b/drivers/staging/fwserial/TODO
index 382a795..c3d1d3a 100644
--- a/drivers/staging/fwserial/TODO
+++ b/drivers/staging/fwserial/TODO
@@ -9,6 +9,5 @@ TODOs prior to this driver moving out of staging
GUID-to-port matching/whitelist/blacklist.

 -- Issues with firewire stack --
-1. This driver uses the same unregistered vendor id that the firewire core does
- (0xd00d1e). Perhaps this could be exposed as a define in
- firewire.h?
+1. This driver uses the same ids that the firewire core does (001f11:0239xx).
+   Perhaps this could be exposed as a define in firewire.h?
diff --git a/drivers/staging/fwserial/fwserial.c 
b/drivers/staging/fwserial/fwserial.c
index 73deae3..2964366 100644
--- a/drivers/staging/fwserial/fwserial.c
+++ b/drivers/staging/fwserial/fwserial.c
@@ -30,8 +30,8 @@

 #define be32_to_u64(hi, lo)  ((u64)be32_to_cpu(hi)  32 | be32_to_cpu(lo))

-#define LINUX_VENDOR_ID   0xd00d1eU  /* same id used in card root directory   
*/
-#define FWSERIAL_VERSION  0x00e81cU  /* must be unique within LINUX_VENDOR_ID 
*/
+#define LINUX_VENDOR_ID   0x001f11U  /* same id used in card root directory   
*/
+#define FWSERIAL_VERSION  0x023953U  /* must be unique within LINUX_VENDOR_ID 
*/

 /* configurable options */
 static int num_ttys = 4;   /* # of std ttys to create per fw_card*/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: file name changes between reboots : /sys/class/hwmon/hwmon[0-1]/temp1_input

[Clemens Ladisch]

Toralf Förster wrote:
 I'm wondering where to blame a nagging issue with these file names :

 # ls -l /sys/class/hwmon/hwmon?/temp?_input
 -r--r--r-- 1 root root 4096 Jan 30 13:57 /sys/class/hwmon/hwmon1/temp1_input
 -r--r--r-- 1 root root 4096 Jan 30 13:57 /sys/class/hwmon/hwmon2/temp1_input
 -r--r--r-- 1 root root 4096 Jan 30 13:57 /sys/class/hwmon/hwmon2/temp2_input
 -r--r--r-- 1 root root 4096 Jan 30 13:57 /sys/class/hwmon/hwmon2/temp3_input

 It appears sometimes after a reboot / new minor stable kernel that the first 
 file name is found in hwmon0 instead of hwmon1.

Those numbers get assigned in the order in which the drivers get
attached, which is essentially random.

You have to use the permanent device path, which isn't as easy.  Run
something like this to find it:

  find /sys -name 'temp*_input'


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

Re: [PATCH] media; firewire: Remove no longer needed fix me comment in firedtv-ci.c for the function,fdtv_ca_ioctl

[Clemens Ladisch]

Nicholas Krause wrote:
 Removes the no longer fix me comment for if we need to set the tuner status 
 with
 the line, avc_tuner_status(fdtv, stat). This line is needed in order to set 
 the
 tuner status after we have through the switch statement checking what fdtv 
 function
 we need to call to use to try and setup the hardware successfully.

You have attempted to describe what fdtv_ca_ioctl() does, but your description
lacks any understanding of what avc_tuner_status() does, or how it might affect
the device, or whether it is necessary.

Please stop spamming us with useless patches.

 Signed-off-by: Nicholas Krause xerofo...@gmail.com
 ---
  drivers/media/firewire/firedtv-ci.c | 1 -
  1 file changed, 1 deletion(-)

 diff --git a/drivers/media/firewire/firedtv-ci.c 
 b/drivers/media/firewire/firedtv-ci.c
 index e63f582..9c038ba 100644
 --- a/drivers/media/firewire/firedtv-ci.c
 +++ b/drivers/media/firewire/firedtv-ci.c
 @@ -201,7 +201,6 @@ static int fdtv_ca_ioctl(struct file *file, unsigned int 
 cmd, void *arg)
   err = -EOPNOTSUPP;
   }

 - /* FIXME Is this necessary? */
   avc_tuner_status(fdtv, stat);

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

Re: [alsa-devel] [PATCH v2] ALSA: usb-audio: Add support for Akai MPC Element USB MIDI controller

[Clemens Ladisch]

Paul Bonser wrote:
 On 01/08/2015 03:56 PM, Clemens Ladisch wrote:
 Paul Bonser wrote:
 The Akai MPC Element incorrectly reports its bInterfaceClass as 255, but
 otherwise implements the USB MIDI spec correctly.

 This adds a quirks-table.h entry which allows the device to be
 recognized as a standard USB MIDI device.

 +++ b/sound/usb/quirks-table.h
 +{
 +   /* Akai MPC Element */
 +   USB_DEVICE(0x09e8, 0x0021),
 +   .driver_info = (unsigned long)  (const struct snd_usb_audio_quirk) {
 +   .ifnum = QUIRK_ANY_INTERFACE,
 +   .type = QUIRK_COMPOSITE,
 +   .data =  (const struct snd_usb_audio_quirk[]) {
 +   {
 +   .ifnum = 0,
 +   .type = QUIRK_IGNORE_INTERFACE
 +   },
 +   {
 +   .ifnum = 1,
 +   .type = QUIRK_MIDI_STANDARD_INTERFACE
 +   },
 +   {
 +   .ifnum = -1
 +   }
 +   }
 +   }
 +},

 Why a composite quirk?  Does a single quirk entry not work?

 A single quirk entry results in an error message in dmesg:
 snd-usb-audio: probe of 3-2:1.0 failed with error -5

That message is normal for unhandled interfaces.

Does it actually prevent the device from working?


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

Re: [alsa-devel] [PATCH v2] ALSA: usb-audio: Add support for Akai MPC Element USB MIDI controller

[Clemens Ladisch]

Paul Bonser wrote:
 The Akai MPC Element incorrectly reports its bInterfaceClass as 255, but
 otherwise implements the USB MIDI spec correctly.

 This adds a quirks-table.h entry which allows the device to be
 recognized as a standard USB MIDI device.

 Signed-off-by: Paul Bonser mister...@gmail.com
 ---
 diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h
 index 8590a32..e869b6c 100644
 --- a/sound/usb/quirks-table.h
 +++ b/sound/usb/quirks-table.h
 @@ -2516,6 +2516,28 @@ YAMAHA_DEVICE(0x7010, UB99),
   }
  },

 +{
 + /* Akai MPC Element */
 + USB_DEVICE(0x09e8, 0x0021),
 + .driver_info = (unsigned long)  (const struct snd_usb_audio_quirk) {
 + .ifnum = QUIRK_ANY_INTERFACE,
 + .type = QUIRK_COMPOSITE,
 + .data =  (const struct snd_usb_audio_quirk[]) {
 + {
 + .ifnum = 0,
 + .type = QUIRK_IGNORE_INTERFACE
 + },
 + {
 + .ifnum = 1,
 + .type = QUIRK_MIDI_STANDARD_INTERFACE
 + },
 + {
 + .ifnum = -1
 + }
 + }
 + }
 +},

Why a composite quirk?  Does a single quirk entry not work?


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

Re: Questions about IOMMU PCIe switch

[Clemens Ladisch]

Raimonds Cicans wrote:
 https://github.com/ljalves/linux_media/issues/66

If the TBS driver works, why don't you use it?

The WARNING from the kernel log indicates a hardware bug in the PCIe
bridge.  Do you have the same card, and do you also get this warning
with kernel 3.16?

I/O virtualization requires handling packets from different devices
differently.  Problems with DMAR might indicate that some PCIe device
does not correctly identify itself as the source of PCIe packets.


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

Re: Questions about IOMMU PCIe switch

[Clemens Ladisch]

Raimonds Cicans wrote:
 We have two kinds of PCIe cards:
 A1 - based on chip B
 A2 - based on same chip B but behind PCIe switch

 Card A1 work flawlessly in any configuration,
 but card A2 work flawlessly only if system
 lack IOMMU or have disabled IOMMU

In theory, such a switch should be transparent.

 Do we have to treat card with PCIe switch in special way?

No.  But the switch has to work correctly, and driver must be
written correctly.

Which switch?  Which driver?


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

Re: timerfd waking up before timer really expires

[Clemens Ladisch]

Lucas De Marchi wrote:
 I was debugging my application and noticed that a timerfd event was being
 triggered *before* the timer expires.

 I reduced the scope of the program to test a single timerfd and measure the
 difference in the result of clock_gettime() between two reads.

 loop_time_fd = setup_timerfd(interval, 0);
 do {
 read(loop_time_fd, events, sizeof(events));
 ... = now_usec();
 } while (1);

 For whatever interval I configure and 1 iterations, what I'm seeing in the
 elapsed vector are values like

 interval +- 70usec

Let us assume that the timer itself is perfectly accurate, and that all
wakeups of your program are immediately when the timerfd becomes ready,
except for one iteration, where there is a scheduling delay.  Then the
measured interval before this delayed wakeup is longer, while the
measured interval after this wakeup is shorter by the same amount.

To detect early wakeups, you must not check whether the interval between
two consecutive wakeups is too short, but whether the interval between
a wakeup and the time when the timerfd was actually started is shorter
than N × the timer interval.


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

Re: [PATCH 2/2] firewire: add a parameter to force the speed of the devices.

[Clemens Ladisch]

Laurent Vivier wrote:
 I was trying to use my old iPod mini firewire (first generation) with
 a new firewire card I put in my PC (VIA Technologies, Inc. VT6306/7/8),
 but the iPod was not mounted and failed with the following error:
 reading config rom failed: no ack
 It appears that the configuration rom cannot be read after the
 device max speed is set to something else than SCODE_100.

 According to the iPod configuration ROM, it should support SCODE_400.

 This patch adds a a parameter (force_speed) to the firewire-core module
 to be able to set the max speed to use with the firewire devices.

Why a module parameter?  Why not automatically apply this workaround to
this specific device?


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

Re: Question about cacheline aligned memory for DMA transfers

[Clemens Ladisch]

Johannes Thoma wrote:
 Does kmalloc return only memory that is cache line aligned?

Yes.

 do all architectures handle cache line misalign ed dma accesses
 correctly?

x86 does.  Most other architectures do not have DMA-coherent caches.


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

Re: [BUG] ohci_enable() fails during resume

[Clemens Ladisch]

Lukasz Stelmach wrote:
 A bit, suddenly by desktop PC started to fail to resume. [...]
 The failing code is somewhere around line 2400 of
 drivers/firewire/ohci.c (the latest mainline).

0x003f +31: callq  0xb037 copy_config_rom
0x0044 +36: mov0x898(%rbx),%rax
 --0x004b +43: mov(%rax),%edx   --

(The copy_config_rom call was not actually executed; the else branch
jumped to 44.)

ohci-next_config_rom is NULL because ohci-config_rom is NULL.

 The code around the line 2400 appears to handle multiple
 firewire ports (if I recognise variable names correctly, e.g.
 next_config_rom).

No, this code handles multiple versions of the same data structure.

 Hardware bug in the on-board firewire controller *and* a bug in the
 driver.

Indeed; this appears to be the culprit:
 [  232.855042] firewire_ohci :04:03.0: added OHCI v1.0 device as card 0, 
 8 IR + 8 IT contexts, quirks 0x0
 [  232.864724] firewire_ohci :04:03.0: bad self ID 0/1 ( != 
 ~)

With the bad self ID, bus_reset_work() just aborts, and the controller
is never completely initialized (therefore the unexpected NULL).

Try unloading and reloading the firewire-ohci module to see if you can
ever avoid the bad self ID error.  But if it stays, your hardware
indeed appears to be broken.


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

Re: RFC: kernel coding style: prefer array to array[0] ?

[Clemens Ladisch]

Joe Perches wrote:
 It seems most in-kernel uses are 'array' rather than 'array[0]'

 Most of the time, using array is simpler to read than array[0].

 Exceptions exists when addresses for consecutive members are
 used like func(array[0], array[1]);

I use 'array[0]' when I want to get a pointer to a single object that
happens to be the first one in an array.

 Should this preference be put into checkpatch and/or CodingStyle?

How about the following low-hanging fruit?

  foo(..., array[0], ARRAY_SIZE(array), ...)


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

Re: [Question] Usage of ENOTSUPP error code

[Clemens Ladisch]

Masahiro Yamada wrote:
 I noticed many drivers return -ENOTSUPP on error.

 I assume ENOTSUPP is defined in include/linux/errno.h
 as follows:

 /* Defined for the NFSv3 protocol */
 ...
 #define ENOTSUPP 524 /* Operation is not supported */

 If so, should ENOTSUPP be only used for NFS-related errors?

There is typcially no such restriction.

However, the problem with ENOTSUPP is that it is not defined in
the uapi header, so it will not be known to user space programs.

 In fact, ENOTSUPP is used by various drivers
 including non-network ones such as pinctrl, USB, etc.

If it is possible that the error code shows up for user space, ENOTSUPP
should not be used.  Alternatives would be something like ENOTSUP,
EOPNOTSUPP, ENOIOCTLCMD, ENOSYS, or EINVAL.


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

Re: [PATCH v2] add stealth mode

[Clemens Ladisch]

valdis.kletni...@vt.edu wrote:
 On Thu, 02 Jul 2015 10:56:01 +0200, Matteo Croce said:
 Add option to disable any reply not related to a listening socket

 2) You *do* realize that this isn't anywhere near sufficient in order
 to actually make your machine invisible, right?  (Hint: What *other*
 packets can be sent to a machine to provoke a response?)

Even worse: if you want to pretend that the entire machine is not there,
you must make the router in front on you reply with an ICMP destination
unreachable message.


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

Re: character driver - poll() timeout

[Clemens Ladisch]

Muni Sekhar wrote:
> Is it possible to print the timeout value in character driver poll() API?

No.  Your driver's poll callback never waits.

Why do you think you need this value?


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

Re: character driver - poll() timeout

[Clemens Ladisch]

Muni Sekhar wrote:
> On Tue, Oct 27, 2015 at 1:41 PM, Clemens Ladisch <clem...@ladisch.de> wrote:
>> Muni Sekhar wrote:
>>> Is it possible to print the timeout value in character driver poll() API?
>>
>> No.  Your driver's poll callback never waits.
>>
>> Why do you think you need this value?
>
> I need to find out when exactly driver's poll callback returned timeout.

Your poll callback _cannot_ return a timeout.

Why do you think you need this information for?


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

Re: character driver - poll() timeout

[Clemens Ladisch]

Muni Sekhar wrote:
> On Tue, Oct 27, 2015 at 8:48 PM, Clemens Ladisch <clem...@ladisch.de> wrote:
>> Muni Sekhar wrote:
>>> I need to find out when exactly driver's poll callback returned timeout.
>>
>> Your poll callback _cannot_ return a timeout.
>>
>> Why do you think you need this information for?
>
> During stress test, my test application fails and throws poll() timeout error.
>
> I need to debug what is the state of my driver during that time. I
> added prints in driver poll(), but I gets lots of debug prints if
> poll() timeout is more.

Your poll() callback does not really change the state of the driver.
It just returns the wait queue and the current state of the device.
(Which means it is likely to get called _twice_, before poll() goes
to sleep, and just before it returns.)

Your driver's state changes only when
1) you start some operation (such as read() or write()), or when
2) you finish some operation (which wakes up anyone waiting on
   that wait queue).

If you time out, it means that some wake_up() happens too late or
not at all, or that you do not return the correct state.


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

Re: [PATCH v5 6/7] usb: gadget: f_midi: set altsettings only for MIDIStreaming interface

[Clemens Ladisch]

Felipe Ferreri Tonello wrote:
> On 10/11/15 18:43, Sergei Shtylyov wrote:
>> On 11/10/2015 08:52 PM, Felipe F. Tonello wrote:
>>> @@ -75,6 +75,7 @@ struct f_midi {
>>>   struct usb_ep*in_ep, *out_ep;
>>>   struct snd_card*card;
>>>   struct snd_rawmidi*rmidi;
>>> +u8ms_id;
>>
>>   Why 'ms_id' is not aligned with the above field names?
>
> It is actually aligned.

It's not in the original mail, which contains tab characters.

> Here is from my local git diff:
>
> @@ -75,6 +75,7 @@ struct f_midi {
> struct usb_ep   *in_ep, *out_ep;
> struct snd_card *card;
> struct snd_rawmidi  *rmidi;
> +   u8  ms_id;

Apparently, you're using four spaces per tab.  Linux uses eight.


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

Re: [PATCH v5 6/7] usb: gadget: f_midi: set altsettings only for MIDIStreaming interface

[Clemens Ladisch]

Felipe F. Tonello wrote:
> This avoids duplication of USB requests for OUT endpoint and
> re-enabling endpoints.

>  ...
>   /* For Control Device interface we do nothing */
> - if (intf == 0)
> + if (intf != midi->ms_id)
>   return 0;

The comment now is misleading.


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

Re: [PATCH v5 7/7] usb: gadget: f_midi: pre-allocate IN requests

[Clemens Ladisch]

Felipe F. Tonello wrote:
> This patch introduces pre-allocation of IN endpoint USB requests. This
> improves on latency (requires no usb request allocation on transmit) and avoid
> several potential probles on allocating too many usb requests (which involves
> DMA pool allocation problems).
>
> This implementation also handles better multiple MIDI Gadget ports, always
> processing the last processed MIDI substream if the last USB request wasn't
> enought to handle the whole stream.

> ...
> +++ b/drivers/usb/gadget/function/f_midi.c
> @@ -88,6 +89,9 @@ struct f_midi {
>   int index;
>   char *id;
>   unsigned int buflen, qlen;
> + DECLARE_KFIFO_PTR(in_req_fifo, struct usb_request *);
> + unsigned int in_req_num;
> + unsigned int in_last_port;

As far as I can see, in_req_num must always have the same value as qlen.

> @@ -366,6 +388,20 @@ static void f_midi_disable(struct usb_function *f)
> + while (!kfifo_is_empty(>in_req_fifo)) {
> + ...
> + len = kfifo_get(>in_req_fifo, );
> + if (len == 1)
> + free_ep_req(midi->in_ep, req);
> + else
> + ERROR(midi, "%s couldn't free usb request: something 
> went wrong with kfifo\n",
> +   midi->in_ep->name);
> + }

kfifo_get() already checks for the FIFO being empty, so you can just
drop kfifi_is_empty().

> @@ -487,57 +523,111 @@ static void f_midi_transmit_byte(struct usb_request 
> *req,
> ...
> +static void f_midi_transmit(struct f_midi *midi)
> +{
> +...
> + len = kfifo_peek(>in_req_fifo, );
> + ...
> + if (req->length > 0) {
> + WARNING(midi, "%s: All USB requests have been used. 
> Current queue size "
> + "is %u, consider increasing it.\n", __func__, 
> midi->in_req_num);
> + goto drop_out;
> + }

There are two cases where the in_req FIFO might overflow:
1) the gadget is trying to send too much data at once; or
2) the host does not bother to read any of the data.

In case 1), the appropriate action would be to do nothing, so that the
remaining data is sent after some currently queued packets have been
transmitted.  In case 2), the appropriate action would be to drop the
data (even better, the _oldest_ data), and spamming the log with error
messages would not help.

This code shows the error message for case 1), but does the action for
case 2).

I'm not quite sure if trying to detect which of these cases we have is
possible, or worthwhile.  Anyway, with a packet size of 64, the queue
size would be 32*64 = 2KB, which should be enough for everyone.  So I
propose to ignore case 1), and to drop the error message.

> @@ -1130,6 +1222,12 @@ static struct usb_function *f_midi_alloc(struct 
> usb_function_instance *fi)
> + if (kfifo_alloc(>in_req_fifo, midi->qlen, GFP_KERNEL))
> + goto setup_fail;

The setup_fail code expects an error code in the status variable.


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

Re: [PATCH] Sound: Usb: Misc: ua101: replace le16_to_cpu() with usb_endpoint_maxp()

[Clemens Ladisch]

Cheah Kok Cheong wrote:
> Commit 939f325f4a0f ("usb: add usb_endpoint_maxp() macro")
>
> And commit 29cc88979a88 ("USB: use usb_endpoint_maxp()
> instead of le16_to_cpu()")

These sentences no verb.

> Patched against
> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git

This does not belong into the commit message.

> Signed-off-by: Cheah Kok Cheong <thrus...@gmail.com>

Otherwise:
Acked-by: Clemens Ladisch <clem...@ladisch.de>

> ---
>  sound/usb/misc/ua101.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/sound/usb/misc/ua101.c b/sound/usb/misc/ua101.c
> index 9581089..c19a5dd 100644
> --- a/sound/usb/misc/ua101.c
> +++ b/sound/usb/misc/ua101.c
> @@ -1037,7 +1037,7 @@ static int detect_usb_format(struct ua101 *ua)
>   return -ENXIO;
>   }
>   ua->capture.usb_pipe = usb_rcvisocpipe(ua->dev, usb_endpoint_num(epd));
> - ua->capture.max_packet_bytes = le16_to_cpu(epd->wMaxPacketSize);
> + ua->capture.max_packet_bytes = usb_endpoint_maxp(epd);
>
>   epd = >intf[INTF_PLAYBACK]->altsetting[1].endpoint[0].desc;
>   if (!usb_endpoint_is_isoc_out(epd)) {
> @@ -1045,7 +1045,7 @@ static int detect_usb_format(struct ua101 *ua)
>   return -ENXIO;
>   }
>   ua->playback.usb_pipe = usb_sndisocpipe(ua->dev, usb_endpoint_num(epd));
> - ua->playback.max_packet_bytes = le16_to_cpu(epd->wMaxPacketSize);
> + ua->playback.max_packet_bytes = usb_endpoint_maxp(epd);
>   return 0;
>  }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] hpet: Delete an unnecessary check before unregister_sysctl_table()

[Clemens Ladisch]

SF Markus Elfring wrote:
> From: Markus Elfring <elfr...@users.sourceforge.net>
> Date: Thu, 5 Nov 2015 21:32:42 +0100
>
> The unregister_sysctl_table() function tests whether its argument is NULL
> and then returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>

Acked-by: Clemens Ladisch <clem...@ladisch.de>

> ---
>  drivers/char/hpet.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
> index 240b6cf..fe511e9 100644
> --- a/drivers/char/hpet.c
> +++ b/drivers/char/hpet.c
> @@ -1069,8 +1069,7 @@ static int __init hpet_init(void)
>
>   result = acpi_bus_register_driver(_acpi_driver);
>   if (result < 0) {
> - if (sysctl_header)
> - unregister_sysctl_table(sysctl_header);
> + unregister_sysctl_table(sysctl_header);
>   misc_deregister(_misc);
>   return result;
>   }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/4] usb: gadget: f_midi: free usb request when done

[Clemens Ladisch]

Felipe Tonello wrote:
> req->actual == req->length means that there is no data left to enqueue,

This condition is not checked in the patch.

> so free the request.
>
> Signed-off-by: Felipe F. Tonello 
> ---
>  drivers/usb/gadget/function/f_midi.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> diff --git a/drivers/usb/gadget/function/f_midi.c 
> b/drivers/usb/gadget/function/f_midi.c
> index edb84ca..93212ca 100644
> --- a/drivers/usb/gadget/function/f_midi.c
> +++ b/drivers/usb/gadget/function/f_midi.c
> @@ -256,9 +256,8 @@ f_midi_complete(struct usb_ep *ep, struct usb_request 
> *req)
>   /* We received stuff. req is queued again, below */
>   f_midi_handle_out_data(ep, req);
>   } else if (ep == midi->in_ep) {
> - /* Our transmit completed. See if there's more to go.
> -  * f_midi_transmit eats req, don't queue it again. */
> - f_midi_transmit(midi, req);
> + /* Our transmit completed. Don't queue it again. */
> + free_ep_req(ep, req);
>   return;
>   }
>   break;

The ALSA framework will give you a notification _once_.  If the
resulting data is larger than midi->buflen, then you have to continue
sending packets.  This is exactly what the call to f_midi_transmit()
does.

(To decrease latency, it might be a good idea to queue multiple requests,
but you wouldn't want to continue piling up requests if the host isn't
listening.  sound/usb/midi.c just allocates a fixed number of requests,
and always reuses them.)


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

Re: [PATCH v3 1/4] usb: gadget: f_midi: free usb request when done

[Clemens Ladisch]

Felipe Balbi wrote:
> Clemens Ladisch <clem...@ladisch.de> writes:
>> Felipe Tonello wrote:
>>> req->actual == req->length means that there is no data left to enqueue,
>>
>> This condition is not checked in the patch.
>>
>>> so free the request.
>>>
>>> Signed-off-by: Felipe F. Tonello <e...@felipetonello.com>
>>> ---
>>>  drivers/usb/gadget/function/f_midi.c | 5 ++---
>>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>> diff --git a/drivers/usb/gadget/function/f_midi.c 
>>> b/drivers/usb/gadget/function/f_midi.c
>>> index edb84ca..93212ca 100644
>>> --- a/drivers/usb/gadget/function/f_midi.c
>>> +++ b/drivers/usb/gadget/function/f_midi.c
>>> @@ -256,9 +256,8 @@ f_midi_complete(struct usb_ep *ep, struct usb_request 
>>> *req)
>>> /* We received stuff. req is queued again, below */
>>> f_midi_handle_out_data(ep, req);
>>> } else if (ep == midi->in_ep) {
>>> -   /* Our transmit completed. See if there's more to go.
>>> -* f_midi_transmit eats req, don't queue it again. */
>>> -   f_midi_transmit(midi, req);
>>> +   /* Our transmit completed. Don't queue it again. */
>>> +   free_ep_req(ep, req);
>>> return;
>>> }
>>> break;
>>
>> The ALSA framework will give you a notification _once_.  If the
>> resulting data is larger than midi->buflen, then you have to continue
>> sending packets.  This is exactly what the call to f_midi_transmit()
>> does.
>
> so, should I drop this series from my TODO queue ?

Yes, this patch needs to be dropped.


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

Re: [PATCH v3 1/4] usb: gadget: f_midi: free usb request when done

[Clemens Ladisch]

Felipe Tonello wrote:
> On Fri, Oct 9, 2015 at 10:23 AM, Clemens Ladisch <clem...@ladisch.de> wrote:
>> Felipe Tonello wrote:
>>>   } else if (ep == midi->in_ep) {
>>> - /* Our transmit completed. See if there's more to go.
>>> -  * f_midi_transmit eats req, don't queue it again. */
>>> - f_midi_transmit(midi, req);
>>> + /* Our transmit completed. Don't queue it again. */
>>> + free_ep_req(ep, req);
>>>   return;
>>>   }
>>>   break;
>>
>> The ALSA framework will give you a notification _once_.  If the
>> resulting data is larger than midi->buflen, then you have to continue
>> sending packets.  This is exactly what the call to f_midi_transmit()
>> does.
>
> That's true. But what it will also happen is that f_midi_transmit()
> will potentially eat up data from an unrelated ALSA trigger.

The triggers are for some MIDI port of the _same_ USB endpoint, so
they're not unrelated.  f_midi_transmit() collects data from all ports
anyway; separating the data from different ports into different USB
packets would just needlessly introduce additional latency.

> In the end it is all fine, because the function will realise the
> request->len == 0 so it will free the request. But logically speaking
> it is incorrect and error prone.

It is _not_ incorrect if you realize that f_midi_transmit() applies to
the endpoint, not to any particular port.

>> (To decrease latency, it might be a good idea to queue multiple requests,
>> but you wouldn't want to continue piling up requests if the host isn't
>> listening.  sound/usb/midi.c just allocates a fixed number of requests,
>> and always reuses them.)
>
> I believe that is the best way to implement. Create multiple requests
> until the ALSA substreams buffer are empty and free the request on
> completion.

I believe a better way to implement this is to allocate a fixed number
of requests, and to always reuse them.

> The problem of having requests when host isn't listening will happen
> anyway because there is no way to know that until completion.

But if you have no upper limit on the number of queues requests, you
will eventually run out of (DMA) memory.


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

Re: [PATCH v3 1/4] usb: gadget: f_midi: free usb request when done

[Clemens Ladisch]

Felipe Tonello wrote:
> On Mon, Oct 12, 2015 at 11:16 AM, Clemens Ladisch <clem...@ladisch.de> wrote:
>> Felipe Tonello wrote:
>>> I believe that is the best way to implement. Create multiple requests
>>> until the ALSA substreams buffer are empty and free the request on
>>> completion.
>>
>> I believe a better way to implement this is to allocate a fixed number
>> of requests, and to always reuse them.
>
> How many?

Enough to get proper pipelining.  At least two, maybe not more.
(Depends on how fast those tiny CPUs can queue the next request.)

>>> The problem of having requests when host isn't listening will happen
>>> anyway because there is no way to know that until completion.
>>
>> But if you have no upper limit on the number of queues requests, you
>> will eventually run out of (DMA) memory.
>
> And that's what happening at the moment. One of my patches are to fix
> a memory leak when that happens.
>
> But it would be ideal to have a FIFO of requests and perhaps ignore
> new requests if the FIFO is full.
>
> So, allocate (pre-allocate?) new requests until the FIFO is full. Upon
> completion, remove the request from FIFO, but still reuse it on
> f_midi_transmit() and queue it on the FIFO again if there is still
> data from ALSA, otherwise just free the request.

Yes, that's exactly what I'm proposing.


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

Re: Possible Bug Found with Xonar Stx Driver

[Clemens Ladisch]

nick wrote:
 After running the latest version of Linus's tree I am noticed way more 
 buffering

What exactly do you mean with the word buffering?

 when playing music with my Xonar STX card when building kernels then
 under the Ubuntu kernel version of 3.19.16.

Sounds like a change in the disk access patterns.

The audio buffer size is chosen by the playing application (whatever it
is).

 I have tried bisecting it between the releases of 3.18 and 4.0
 and was unable to narrow it down to a buggy commit.

There was no relevant change in the sound driver.


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

Re: tools: usbip: detach: avoid calling strlen() at each iteration

[Clemens Ladisch]

Aaro Koskinen wrote:
> On Tue, Sep 15, 2015 at 09:27:20PM +0100, Eric Curtin wrote:
>> -for (unsigned int i = 0; i < strlen(port); i++)
>> +unsigned int port_len = strlen(port);
>> +
>> +for (unsigned int i = 0; i < port_len; i++)
>
> port is read only in this function, so maybe just use "const" and the
> compiler should know to do the same without adding a new variable?

If the compiler knows the implementation of strlen() (because it's
a built-in function), then it sees that nobody modifies port[] in the
loop.  If the compiler does not know the implementation of strlen()
(because -fno-builtins is used), then it is possible that some other
function has a valid non-const pointer and modifies the data through it.

(Anyway, the detach_port() function is not time critical, so I don't
think that optimizing it is worthwhile if it reduces readability.  But
seeing the strlen() call at that place grates on me; I'm not against
moving it out of the loop.)

The loop goes through the string one character at a time, so it might
be possible to drop strlen() altogether and just stop the loop when the
end of the string is reached.

But the actual purpose of the loop is to check whether there is a valid
number.  This could be done more easily by replacing the loop and the
following atoi() call with strtol().


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

Re: [PATCH v2 2/3] usb: gadget: f_midi: free usb request when done

[Clemens Ladisch]

Peter Chen wrote:
> I can't make my aplaymidi to receive data

> # aplaymidi
> open /dev/snd/seq failed: No such file or directory

modprobe snd-seq

There are mechanisms to load it automatically, but your embedded system
might not bother about any of them.  Or CONFIG_SND_SEQUENCER isn't
enabled at all.

In any case, raw MIDI (with the amidi tool) should work.


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

Re: [PATCH v5 7/7] usb: gadget: f_midi: pre-allocate IN requests

[Clemens Ladisch]

Felipe Ferreri Tonello wrote:
> One thing to consider is that the ALSA rawmidi device buffer is
> sequential and our USB request buffer is not. This means that our 32
> (qlen) * 256 (buflen) = 8KB of data is non-linear. Some requests might
> have 3 or 4 bytes (average size of a normal MIDI message) of data and
> some others might contain the full 256 bytes (for SysEx messages).

f_midi_transmit() always fills up the USB packet as much as possible, so
the number of MIDI messages per request will increase automatically when
the ALSA buffer fills up faster that it is emptied by f_midi.

> == Conclusion ==
>
> Based on our conversation and your suggestions, I think that to just
> ignore if an overrun occurs to the USB requests is fine. Upon completion
> the request will be reused.
> Important to note that if the overrun occurs, it will cause user-space
> to block until a) the completion function is called successfully or b)
> snd_rawmidi_write() times out. Which I think this is expected by ALSA users.
>
> Does that make sense?

Yes.


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

Re: Ques: [kernel/time/*] Is there any disadvantage in using usleep_range for more than 20ms delay ?

[Clemens Ladisch]

Aniroop Mathur wrote:
> As in the kernel documentation, it is mentioned to use msleep for
> 10ms+ delay, I am confused whether there would be any disadvantage in
> using usleep_range for higher delays values because normally drivers
> have variety of delays used (2, 10, 20, 40, 100, 500 ms).
>
> So, could you please help to confirm that if we use usleep_range for
> inserting delays greater than 20 ms, would it be harmful or beneficial
> or does not make any difference at all ?

As the documentation told you, usleep_range() is likely to require
a separate interrupt, while msleep() is likely to round to some other,
already-scheduled interrupt.  The former is possibly harmful regarding
CPU and power usage; you have to balance it against your need for
accuracy.

(And usleep_range() has a 32-bit nanosecond limit on 32-bit
architectures.)


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

Re: A new, fast and "unbreakable" encryption algorithm

[Clemens Ladisch]

Ismail Kizir wrote:
> What means "did not look random"?

A plaintext consisting of repeated bytes (zero, or other values)
eventually makes your algorithm go into a loop, which results in
repeated bytes.

> On the pictures, there is also an example of "full 0"(it appears red,
> but it is full 0 bmp) example.
> And it "looks" perfectly random.

No, red is _not_ perfectly random.  When I see a red picture, I have
evidence that the plaintext was zeroes.


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

Re: [PATCH] Documentation: email-clients.txt

[Clemens Ladisch]

Sanidhya Solanki wrote:
>  Claws Mail (GUI)
>
> -Works. Some people use this successfully for patches.
> +Tested and Works as of December 2015. Some people use this successfully
> +for patches.

"Some people" still doesn't include you:

> -Thunderbird is an Outlook clone that likes to mangle text, but there
> are ways -to coerce it into behaving.
> +Thunderbird is an Outlook clone that likes to mangle text, but there
> are +ways to coerce it into behaving. In December 2015, the internal
> editor +options do not appear to work.

How exactly?  Thunderbird appears to work for me, and doesn't break long lines 
or sends plain text as "flowed".

And version numbers might be more useful than dates.


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

Re: [PATCH] ALSA: usb-audio: constify usb_protocol_ops structures

[Clemens Ladisch]

Julia Lawall wrote:
> The usb_protocol_ops structures are never modified, so declare them as
> const.
>
> Done with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall <julia.law...@lip6.fr>

Acked-by: Clemens Ladisch <clem...@ladisch.de>

> ---
>  sound/usb/midi.c |   25 +
>  1 file changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/sound/usb/midi.c b/sound/usb/midi.c
> index ee212e7..cc39f63 100644
> --- a/sound/usb/midi.c
> +++ b/sound/usb/midi.c
> @@ -112,7 +112,7 @@ struct snd_usb_midi {
>   struct usb_interface *iface;
>   const struct snd_usb_audio_quirk *quirk;
>   struct snd_rawmidi *rmidi;
> - struct usb_protocol_ops *usb_protocol_ops;
> + const struct usb_protocol_ops *usb_protocol_ops;
>   struct list_head list;
>   struct timer_list error_timer;
>   spinlock_t disc_lock;
> @@ -671,31 +671,32 @@ static void snd_usbmidi_standard_output(struct 
> snd_usb_midi_out_endpoint *ep,
>   }
>  }
>
> -static struct usb_protocol_ops snd_usbmidi_standard_ops = {
> +static const struct usb_protocol_ops snd_usbmidi_standard_ops = {
>   .input = snd_usbmidi_standard_input,
>   .output = snd_usbmidi_standard_output,
>   .output_packet = snd_usbmidi_output_standard_packet,
>  };
>
> -static struct usb_protocol_ops snd_usbmidi_midiman_ops = {
> +static const struct usb_protocol_ops snd_usbmidi_midiman_ops = {
>   .input = snd_usbmidi_midiman_input,
>   .output = snd_usbmidi_standard_output,
>   .output_packet = snd_usbmidi_output_midiman_packet,
>  };
>
> -static struct usb_protocol_ops snd_usbmidi_maudio_broken_running_status_ops 
> = {
> +static const
> +struct usb_protocol_ops snd_usbmidi_maudio_broken_running_status_ops = {
>   .input = snd_usbmidi_maudio_broken_running_status_input,
>   .output = snd_usbmidi_standard_output,
>   .output_packet = snd_usbmidi_output_standard_packet,
>  };
>
> -static struct usb_protocol_ops snd_usbmidi_cme_ops = {
> +static const struct usb_protocol_ops snd_usbmidi_cme_ops = {
>   .input = snd_usbmidi_cme_input,
>   .output = snd_usbmidi_standard_output,
>   .output_packet = snd_usbmidi_output_standard_packet,
>  };
>
> -static struct usb_protocol_ops snd_usbmidi_ch345_broken_sysex_ops = {
> +static const struct usb_protocol_ops snd_usbmidi_ch345_broken_sysex_ops = {
>   .input = ch345_broken_sysex_input,
>   .output = snd_usbmidi_standard_output,
>   .output_packet = snd_usbmidi_output_standard_packet,
> @@ -795,7 +796,7 @@ static void snd_usbmidi_akai_output(struct 
> snd_usb_midi_out_endpoint *ep,
>   }
>  }
>
> -static struct usb_protocol_ops snd_usbmidi_akai_ops = {
> +static const struct usb_protocol_ops snd_usbmidi_akai_ops = {
>   .input = snd_usbmidi_akai_input,
>   .output = snd_usbmidi_akai_output,
>  };
> @@ -835,7 +836,7 @@ static void snd_usbmidi_novation_output(struct 
> snd_usb_midi_out_endpoint *ep,
>   urb->transfer_buffer_length = 2 + count;
>  }
>
> -static struct usb_protocol_ops snd_usbmidi_novation_ops = {
> +static const struct usb_protocol_ops snd_usbmidi_novation_ops = {
>   .input = snd_usbmidi_novation_input,
>   .output = snd_usbmidi_novation_output,
>  };
> @@ -867,7 +868,7 @@ static void snd_usbmidi_raw_output(struct 
> snd_usb_midi_out_endpoint *ep,
>   urb->transfer_buffer_length = count;
>  }
>
> -static struct usb_protocol_ops snd_usbmidi_raw_ops = {
> +static const struct usb_protocol_ops snd_usbmidi_raw_ops = {
>   .input = snd_usbmidi_raw_input,
>   .output = snd_usbmidi_raw_output,
>  };
> @@ -883,7 +884,7 @@ static void snd_usbmidi_ftdi_input(struct 
> snd_usb_midi_in_endpoint *ep,
>   snd_usbmidi_input_data(ep, 0, buffer + 2, buffer_length - 2);
>  }
>
> -static struct usb_protocol_ops snd_usbmidi_ftdi_ops = {
> +static const struct usb_protocol_ops snd_usbmidi_ftdi_ops = {
>   .input = snd_usbmidi_ftdi_input,
>   .output = snd_usbmidi_raw_output,
>  };
> @@ -927,7 +928,7 @@ static void snd_usbmidi_us122l_output(struct 
> snd_usb_midi_out_endpoint *ep,
>   urb->transfer_buffer_length = ep->max_transfer;
>  }
>
> -static struct usb_protocol_ops snd_usbmidi_122l_ops = {
> +static const struct usb_protocol_ops snd_usbmidi_122l_ops = {
>   .input = snd_usbmidi_us122l_input,
>   .output = snd_usbmidi_us122l_output,
>  };
> @@ -1060,7 +1061,7 @@ static void snd_usbmidi_emagic_output(struct 
> snd_usb_midi_out_endpoint *ep,
>   urb->transfer_buffer_length = ep->max_transfer - buf_free;
>  }
>
> -static struct usb_protocol_ops snd_usbmidi_emagic_ops = {
&

Re: [PATCH 1/2] usb: gadget: f_midi: refactor state machine

[Clemens Ladisch]

Felipe F. Tonello wrote:
> This refactor includes the following:
>  * Cleaner state machine code;

It does not correctly handle system real time messages inserted between
the status and data bytes of other messages.

>  * Reset state if MIDI message parsed is non-conformant;

Why?  In a byte stream like "C1 C3 44", where the data byte of the first
message was lost, the reset would also drop the second message.

>  * Fixed bug when a conformant MIDI message was followed by a non-conformant
>causing the MIDI-USB message to use old temporary data (port->data[0..1]),
>thus packing a wrong MIDI-USB request.

Running status is feature.


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

Re: [PATCH 1/2] usb: gadget: f_midi: refactor state machine

[Clemens Ladisch]

Felipe Ferreri Tonello wrote:
>> Running status is feature.
>
>What do you mean by that?

That this behavior is intended, and required.

> I don't qualify writing a *wrong* MIDI-USB
>packet because of a previous MIDI message as a feature.

The MIDI Specification qualifies Running Status as a feature.


Regards,
Clemens

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

Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory

[Clemens Ladisch]

Mathias Krause wrote:
> [...]
> So, prior extending the usage of the __read_only annotation some
> toolchain support is needed. Maybe a gcc plugin that'll warn/error on
> code that writes to such a variable but is not __init itself.

Or mark them as "const".  This would require the initialization code to
cast it away, probably with a helper macro.


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

Re: [PATCH v5 7/7] usb: gadget: f_midi: pre-allocate IN requests

[Clemens Ladisch]

Felipe Ferreri Tonello wrote:
> On 13/11/15 08:55, Clemens Ladisch wrote:
>> Felipe F. Tonello wrote:
>>> +static void f_midi_transmit(struct f_midi *midi)
>>> +{
>>> +...
>>> +   len = kfifo_peek(>in_req_fifo, );
>>> +   ...
>>> +   if (req->length > 0) {
>>> +   WARNING(midi, "%s: All USB requests have been used. 
>>> Current queue size "
>>> +   "is %u, consider increasing it.\n", __func__, 
>>> midi->in_req_num);
>>> +   goto drop_out;
>>> +   }
>>
>> There are two cases where the in_req FIFO might overflow:
>> 1) the gadget is trying to send too much data at once; or
>> 2) the host does not bother to read any of the data.
>>
>> In case 1), the appropriate action would be to do nothing, so that the
>> remaining data is sent after some currently queued packets have been
>> transmitted.  In case 2), the appropriate action would be to drop the
>> data (even better, the _oldest_ data), and spamming the log with error
>> messages would not help.
>
> True. In this case the log will be spammed.
>
> How would you suggest to drop the oldest data? That doesn't really seem
> to be feasible.

There is usb_ep_dequeue().  Its documentation warns about some hardware,
but it would be possible to at least try it.

>> I'm not quite sure if trying to detect which of these cases we have is
>> possible, or worthwhile.  Anyway, with a packet size of 64, the queue
>> size would be 32*64 = 2KB, which should be enough for everyone.  So I
>> propose to ignore case 1), and to drop the error message.

After some thought, I'm not so sure anymore -- the ability to buffer
more than 2 KB of data is part of the snd_rawmidi_write() API, so this
could introduce a regression.  And I can imagine cases where one would
actually want to transmit large amounts data.

I think the safest approach would be to behave similar to the old driver,
i.e., when the queue overflows, do nothing (not even dropping data), and
rely on the transmit completion handler to continue.  (This implies that
ALSA's buffer can fill up, and that snd_rawmidi_write() can block.)


It you want to dequeue outdated data, I think this should be done with
a timeout, i.e., when the host did not read anything for some tens of
milliseconds or so.  This would be independent of the fill level of the
queue, and could be done either for individual packets, or just on the
entire endpoint queue.


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

Re: A new, fast and "unbreakable" encryption algorithm

[Clemens Ladisch]

Ismail Kizir wrote:
> The essential logic of the algorithm is using the key as a "jump
> table" which is dynamically updated with every "jump" we make.

Sounds like RC4.  Please tell us how you are avoiding the weaknesses
that make RC4 insecure.

> Briefly, to decypher a ciphertext, a cracker needs to find out the
> key, and, to find out the key, cracker needs to find out the
> plaintext, because the key is dynamically updated according the
> plaintext during encryption process: Impossible!

That problem has been solved for a long time:
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation


Anyway, I tried to modify your program to encrypt a large message
consisting only of zero bytes.  The result did not look random.


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

Re: [PATCH v7 0/5] usb: usbtmc: Add support for missing functions in USBTMC-USB488 spec

[Clemens Ladisch]

Dave Penkler wrote:
> Implement support for the USB488 defined READ_STATUS_BYTE ioctl (1/5)
> and SRQ notifications with fasync (2/5) and poll/select (3/5) in order
> to be able to synchronize with variable duration instrument
> operations.
>
> Add convenience ioctl to return all device capabilities (4/5)
>
> Add ioctls for other USB488 requests: REN_CONTROL, GOTO_LOCAL and
> LOCAL_LOCKOUT. (5/5)
> [...]
>  Testing:
> All functions tested ok on an USBTMC-USB488 compliant oscilloscope

How?  Did you extend the usbtmc_ioctl tool?


Regards,
Clemens

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

[Clemens Ladisch]

Steve Calfee wrote:
> On Wed, Mar 9, 2016 at 11:39 AM, Felipe F. Tonello  
> wrote:
>> [...]
>> This patch fixes this problem by setting the minimum usb_request's buffer 
>> size
>> for the OUT endpoint as its wMaxPacketSize.
>>
>> --- a/drivers/usb/gadget/function/f_midi.c
>> +++ b/drivers/usb/gadget/function/f_midi.c
>> @@ -366,7 +366,9 @@ static int f_midi_set_alt(struct usb_function *f, 
>> unsigned intf, unsigned alt)
>> struct usb_request *req =
>> -   midi_alloc_ep_req(midi->out_ep, midi->buflen);
>> +   midi_alloc_ep_req(midi->out_ep,
>> +   max_t(unsigned, midi->buflen,
>> +   bulk_out_desc.wMaxPacketSize));
>
> Won't you get a buffer overrun if midi->buflen is less than wMaxPacketSize?

No.  f_midi_handle_out_data() uses only the request buffer.


Regards,
Clemens

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

[Clemens Ladisch]

Felipe Ferreri Tonello wrote:
> On 11/03/16 23:07, Michal Nazarewicz wrote:
>> I’m also wondering whether it would be beneficial to get rid of buflen
>> all together and use wMaxPacketSie for in endpoints as well?  Is that
>> feasible?
>
> Yes, we could just remove the buflen parameter.
>
> The only scenario where I can see buflen been "useful" is if the user
> wants to have a smaller buffer size for the OUT endpoint. Should we
> support this case or not?

Splitting data into multiple packets would not make sense from
a performance perspective.  The only possible reason would be to work
around a (theoretical) bug in some host software that does not handle
larger buffers, but there aren't that many host implementations, and I
am not aware of any with such a bug.


Regards,
Clemens

Re: [PATCH v2 06/14] USB: ch341: reinitialize chip on reconfiguration

[Clemens Ladisch]

Grigori Goronzy wrote:
> Changing the LCR register after initialization does not seem to be
> reliable on all chips (particularly not on CH341A).  Restructure
> initialization and configuration to always reinit the chip on
> configuration changes instead and pass the LCR register value directly
> to the initialization command.

> +++ b/drivers/usb/serial/ch341.c
> @@ -155,9 +157,7 @@ static int ch341_set_baudrate(struct usb_device *dev,
>   a = (factor & 0xff00) | divisor;
>   b = factor & 0xff;
>
> - r = ch341_control_out(dev, 0x9a, 0x1312, a);
> - if (!r)
> - r = ch341_control_out(dev, 0x9a, 0x0f2c, b);
> + r = ch341_control_out(dev, CH341_SERIAL_INIT, 0x9c | (ctrl << 8) , a | 
> 0x80);

The variable b is no longer used, so it is no longer necessary to
compute the lower eight bits of the factor.


Regards,
Clemens

Re: [PATCH 1/5] usb: gadget: f_midi: refactor state machine

[Clemens Ladisch]

Felipe Ferreri Tonello wrote:
> On 03/03/16 11:38, Clemens Ladisch wrote:
>> But in what way was the old state machine not "proper"?
>
> Because it didn't reflect all the correct and possible MIDI states

The whole point of the one-byte real-time messages is that they do not
affect the parsing of the surrounding MIDI stream.  So not making them
part of the state machine is the proper way of handling them.  (Also
see the flowchart in appendix A of the spec.)

> This patch doesn't change any functionality. But the important thing
> here is that it improves the driver maintainability [...]

Then I won't get in the way of this driver's maintainer.


Regards,
Clemens

Re: [PATCH 1/5] usb: gadget: f_midi: refactor state machine

[Clemens Ladisch]

Felipe Ferreri Tonello wrote:
> On March 4, 2016 8:07:40 AM GMT+00:00, Clemens Ladisch <clem...@ladisch.de> 
> wrote:
>> Felipe Ferreri Tonello wrote:
>>> On 03/03/16 11:38, Clemens Ladisch wrote:
>>>> But in what way was the old state machine not "proper"?
>>>
>>> Because it didn't reflect all the correct and possible MIDI states
>>
>> The whole point of the one-byte real-time messages is that they do not
>> affect the parsing of the surrounding MIDI stream.  So not making them
>> part of the state machine is the proper way of handling them.  (Also
>> see the flowchart in appendix A of the spec.)
>
> I really don't get your point. So why do we have a state machine at all?

To parse all the other messages.


Regards,
Clemens

Re: [PATCH 1/5] usb: gadget: f_midi: refactor state machine

[Clemens Ladisch]

Felipe F. Tonello wrote:
> This refactor results in a cleaner state machine code

It increases the number of states, and now juggles two state variables.
I cannot agree to it being cleaner.

> and as a result fixed a bug when packaging a USB-MIDI packet right after
> a non-conformant MIDI byte stream.

I have been unable to determine where exactly the new code behaves
differently.  Can you show an example?


Regards,
Clemens

Re: [PATCH 1/5] usb: gadget: f_midi: refactor state machine

[Clemens Ladisch]

Felipe Ferreri Tonello wrote:
> On 02/03/16 21:09, Clemens Ladisch wrote:
>> Felipe F. Tonello wrote:
>>> This refactor results in a cleaner state machine code
>>
>> It increases the number of states, and now juggles two state variables.
>> I cannot agree to it being cleaner.
>
> Yes, it increases the number of states. That was done in order to
> actually implement a proper finite state machine with one state at a
> time and a transition state.

I know, "clean" is subjective.  But in what way was the old state
machine not "proper"?

And how is handling two states (port->state and next_state) cleaner?
As far as I can tell, the requirement for a separate variable comes not
from any inherent complexity of the state machine itself, but only
because the transmit_packet function was inlined.


Regards,
Clemens

Re: [PATCH] usb: core: Do not use sizeof on pointer type

[Clemens Ladisch]

Vaishali Thakkar wrote:
> When sizeof is applied to a pointer typed expression, it gives
> the size of the pointer.

And why would that be wrong in this case?

> +++ b/drivers/usb/core/hcd.c
> @@ -1386,7 +1386,7 @@ static int hcd_alloc_coherent(struct usb_bus *bus,
>   return -EFAULT;
>   }
>
> - vaddr = hcd_buffer_alloc(bus, size + sizeof(vaddr),
> + vaddr = hcd_buffer_alloc(bus, size + sizeof(*vaddr),
>mem_flags, dma_handle);
>   if (!vaddr)
>   return -ENOMEM;
>

Please note the following comment:

/*
 * Store the virtual address of the buffer at the end
 * of the allocated dma buffer. [...]


Regards,
Clemens

Re: [alsa-devel] linux-4.6-rc4/sound/pci/ens1370.c:1551: possible bad expression ?

[Clemens Ladisch]

David Binderman wrote:
> [linux-4.6-rc4/sound/pci/ens1370.c:1551]: (style) Expression '(X & 0xf)>= 
> 0x4' is always false.

What tool generated this message?

> Source code is
>
> if ((ensoniq->ctrl & ES_1371_GPIO_OUTM)>= 4)
> val = 1;

This message is wrong; it is certainly possible for this to be true.

However, there is a different bug: 4 must be ES_1371_GPIO_OUT(4).


Regards,
Clemens

Re: [RFC PATCH 0/5] USB Audio Gadget refactoring

[Clemens Ladisch]

Ruslan Bilovol wrote:
> On Fri, Jul 15, 2016 at 10:43 AM, Clemens Ladisch <clem...@ladisch.de> wrote:
>>>> On Tue, May 24, 2016 at 2:50 AM, Ruslan Bilovol
>>>> <ruslan.bilo...@gmail.com> wrote:
>>>>> it may break current usecase for some people
>>
>> And what are the benefits that justify breaking the kernel API?
>
> Main limitation with current f_uac1 design is - it can be used only on systems
> with real ALSA card present and can have only exact number of
> channels / sampling rate as sink card has. [...]
> A real cases when it's required to have UAC1 gadget represented as virtual
> sound card on gadget side: [...]

Thanks.

> Of course disadvantage of new approach for UAC1 gadget is you need to
> use some userspace application for routing audio from virtual to real
> sound card, like in case of UAC2 gadget. But thanks to existing
> applications like alsaloop it's not difficult nowadays.

I don't know what the maintainer will say, but you would increase the
chances of this change being accepted when you show a concrete example
of how to change the userspace configuration from the old to the new
driver.  (And add it to the documentation.)


Regards,
Clemens

Re: [RFC PATCH 0/5] USB Audio Gadget refactoring

[Clemens Ladisch]

>> On Tue, May 24, 2016 at 2:50 AM, Ruslan Bilovol
>>  wrote:
>>> it may break current usecase for some people

And what are the benefits that justify breaking the kernel API?


Regards,
Clemens

Re: [PATCH v2 0/3] USB Audio Gadget refactoring

[Clemens Ladisch]

Peter Chen wrote:
> I find UAC2 (UAC1 is ok)  support is not well with the latest mainline
> kernel w/o your patch set. The windows7 can't install the driver
> successfully

Windows does not have UAC2 support.

> and the playback shows underrun (using local codec)
> using Linux host.

> # arecord -f dat -t wav -D hw:1,0 | aplay -D hw:0,0 &

The clocks of the two devices are not synchronized.

In the ALSA API, a PCM device is assumed to have its own clock, so it is
not possible to synchronize the USB gadget to the actual sound device
without some separate mechanism (like the old uac1 gadget probably has).


Regards,
Clemens

Re: [PATCH v2 0/3] USB Audio Gadget refactoring

[Clemens Ladisch]

Peter Chen wrote:
> On Tue, Aug 16, 2016 at 11:32:55AM +0200, Clemens Ladisch wrote:
>> Windows does not have UAC2 support.
>
> Thanks, before windows7 or all windows versions have no UAC2 support?

So far, no version has it.


Regards,
Clemens

Re: [alsa-devel] [RFC] [ALSA][CONTROL] Added 2 ioctls for reading/writing values of multiple controls in one go (at once)

[Clemens Ladisch]

Satendra Singh Thakur wrote:
> -Added an ioctl to read values of multiple elements at once
> -Added an ioctl to write values of multiple elements at once
> -In the absence of above ioctls user needs to call N ioctls to
>  read/write value of N elements which requires N context switches

And why are these N context switches a problem?

> -Above mentioned ioctl will be useful for alsa utils such as amixer
>  which reads all controls of given sound card

Is there a noticeable difference?


Regards,
Clemens

Re: [alsa-devel] [PATCH 6/7] dmasound_core: Move two assignments for the variable "ret" in state_open()

[Clemens Ladisch]

SF Markus Elfring wrote:
> A local variable was set to an error code in two cases before a concrete
> error situation was detected.

And why would that be a problem?

http://yarchive.net/comp/linux/error_jumps.html

> - ret = -EBUSY;
> - if (state.busy)
> + if (state.busy) {
> + ret = -EBUSY;
>   goto out;
> + }


Regards,
Clemens

Re: [alsa-devel] [PATCH 0/6] constify snd_pcm_ops structures

[Clemens Ladisch]

Julia Lawall wrote:
> Constify snd_pcm_ops structures.

For 3/5/6:
Acked-by: Clemens Ladisch <clem...@ladisch.de>

Re: [alsa-devel] [PATCH] ALSA: usb: constify snd_pcm_ops structures

[Clemens Ladisch]

Julia Lawall wrote:
> Check for snd_pcm_ops structures that are only stored in the ops field of a
> snd_soc_platform_driver structure or passed as the third argument to
> snd_pcm_set_ops.  The corresponding field or parameter is declared const,
> so snd_pcm_ops structures that have this property can be declared as const
> also.
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
>
> // 
> @r disable optional_qualifier@
> identifier i;
> position p;
> @@
> static struct snd_pcm_ops i@p = { ... };
>
> @ok1@
> identifier r.i;
> struct snd_soc_platform_driver e;
> position p;
> @@
> e.ops = @p;
>
> @ok2@
> identifier r.i;
> expression e1, e2;
> position p;
> @@
> snd_pcm_set_ops(e1, e2, @p)
>
> @bad@
> position p != {r.p,ok1.p,ok2.p};
> identifier r.i;
> struct snd_pcm_ops e;
> @@
> e@i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r.i;
> @@
> static
> +const
>  struct snd_pcm_ops i = { ... };
> // 
>
> Signed-off-by: Julia Lawall <julia.law...@lip6.fr>

Acked-by: Clemens Ladisch <clem...@ladisch.de>

> ---
>  sound/usb/6fire/pcm.c   |2 +-
>  sound/usb/caiaq/audio.c |2 +-
>  sound/usb/hiface/pcm.c  |2 +-
>  sound/usb/misc/ua101.c  |4 ++--
>  sound/usb/usx2y/usx2yhwdeppcm.c |2 +-
>  5 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/sound/usb/6fire/pcm.c b/sound/usb/6fire/pcm.c
> index 36f4115..224a6a5 100644
> --- a/sound/usb/6fire/pcm.c
> +++ b/sound/usb/6fire/pcm.c
> @@ -555,7 +555,7 @@ static snd_pcm_uframes_t usb6fire_pcm_pointer(
>   return ret;
>  }
>
> -static struct snd_pcm_ops pcm_ops = {
> +static const struct snd_pcm_ops pcm_ops = {
>   .open = usb6fire_pcm_open,
>   .close = usb6fire_pcm_close,
>   .ioctl = snd_pcm_lib_ioctl,
> diff --git a/sound/usb/hiface/pcm.c b/sound/usb/hiface/pcm.c
> index 2c44139..23e66ed 100644
> --- a/sound/usb/hiface/pcm.c
> +++ b/sound/usb/hiface/pcm.c
> @@ -511,7 +511,7 @@ static snd_pcm_uframes_t hiface_pcm_pointer(struct 
> snd_pcm_substream *alsa_sub)
>   return bytes_to_frames(alsa_sub->runtime, dma_offset);
>  }
>
> -static struct snd_pcm_ops pcm_ops = {
> +static const struct snd_pcm_ops pcm_ops = {
>   .open = hiface_pcm_open,
>   .close = hiface_pcm_close,
>   .ioctl = snd_pcm_lib_ioctl,
> diff --git a/sound/usb/usx2y/usx2yhwdeppcm.c b/sound/usb/usx2y/usx2yhwdeppcm.c
> index 90766a9..1f28cb2a 100644
> --- a/sound/usb/usx2y/usx2yhwdeppcm.c
> +++ b/sound/usb/usx2y/usx2yhwdeppcm.c
> @@ -587,7 +587,7 @@ static int snd_usX2Y_usbpcm_close(struct 
> snd_pcm_substream *substream)
>  }
>
>
> -static struct snd_pcm_ops snd_usX2Y_usbpcm_ops =
> +static const struct snd_pcm_ops snd_usX2Y_usbpcm_ops =
>  {
>   .open = snd_usX2Y_usbpcm_open,
>   .close =snd_usX2Y_usbpcm_close,
> diff --git a/sound/usb/misc/ua101.c b/sound/usb/misc/ua101.c
> index c19a5dd..71a0e9e 100644
> --- a/sound/usb/misc/ua101.c
> +++ b/sound/usb/misc/ua101.c
> @@ -890,7 +890,7 @@ static snd_pcm_uframes_t playback_pcm_pointer(struct 
> snd_pcm_substream *subs)
>   return ua101_pcm_pointer(ua, >playback);
>  }
>
> -static struct snd_pcm_ops capture_pcm_ops = {
> +static const struct snd_pcm_ops capture_pcm_ops = {
>   .open = capture_pcm_open,
>   .close = capture_pcm_close,
>   .ioctl = snd_pcm_lib_ioctl,
> @@ -903,7 +903,7 @@ static struct snd_pcm_ops capture_pcm_ops = {
>   .mmap = snd_pcm_lib_mmap_vmalloc,
>  };
>
> -static struct snd_pcm_ops playback_pcm_ops = {
> +static const struct snd_pcm_ops playback_pcm_ops = {
>   .open = playback_pcm_open,
>   .close = playback_pcm_close,
>   .ioctl = snd_pcm_lib_ioctl,
> diff --git a/sound/usb/caiaq/audio.c b/sound/usb/caiaq/audio.c
> index 8f66ba7..af5ad84 100644
> --- a/sound/usb/caiaq/audio.c
> +++ b/sound/usb/caiaq/audio.c
> @@ -338,7 +338,7 @@ unlock:
>  }
>
>  /* operators for both playback and capture */
> -static struct snd_pcm_ops snd_usb_caiaq_ops = {
> +static const struct snd_pcm_ops snd_usb_caiaq_ops = {
>   .open = snd_usb_caiaq_substream_open,
>   .close =snd_usb_caiaq_substream_close,
>   .ioctl =snd_pcm_lib_ioctl,

Re: [PATCH v2 2/4] samples: move timers example code from Documentation

[Clemens Ladisch]

Shuah Khan wrote:
> Move timers examples to samples and remove it from Documentation
> Makefile. Create a new Makefile to build timers. It can be built
> from top level directory or from timers directory:
>
> Run make -C samples/timers or cd samples/timers; make
>
> Acked-by: Jonathan Corbet <cor...@lwn.net>
> Signed-off-by: Shuah Khan <shua...@osg.samsung.com>

Acked-by: Clemens Ladisch <clem...@ladisch.de>

Re: Multiple problems with the Linux kernel on an AMD desktop

[Clemens Ladisch]

Rogério Brito wrote:
> [  130.007219] evbug: Event. Dev: input6, Type: 0, Code: 0, Value: 0

The evbug module is intended for debugging; it dumps all input events
into syslog.  If you do not want these messages, do not load this module.
(If it is loaded automatically, you have an actual bug.)


Regards,
Clemens

Re: Multiple problems with the Linux kernel on an AMD desktop

[Clemens Ladisch]

Rogério Brito wrote:
> * I have never been able to boot this computer of mine without the option
>   irqpoll---otherwise, I get the nobody cared message.

The "nobody cared" message indicates that there were too many interrupts
that no driver felt responsible for, so the kernel has disabled that
interrupt vector.  The irqpoll option is a workaround to get the devices
on that interrupt vector to work, but it's not perfect.

It's possible that most of your problems are caused by the irqpoll option.

What IRQ is the problematic one (see the "nobody cared" message)?  What
devices are connected to it (see /proc/interrupts)?  Does the problem go
away when you prevent the corresponding driver(s) from loading?


Regards,
Clemens

Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize

[Clemens Ladisch]

Jiada Wang wrote:
> since commit 57e6dae1087bbaa6b33d3dd8a8e90b63888939a3 the expected packetsize 
> is always limited to
> nominal + 25%. It was discovered, that some devices

Which devices?

> have a much higher jitter in used packetsizes than 25%

How high?  (Please note that the USB specification restricts the jitter
to at most one frame in consecutive packets.)

> which would result in BABBLE condition and dropping of packets.
> A better solution is so assume the jitter to be the nominal packetsize

This solution is better for this one particular device, but how does it
affect normal devices, or the Scarlett 2i4 on EHCI affected?


Regards,
Clemens

Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize

[Clemens Ladisch]

Takashi Iwai wrote:
> Clemens Ladisch wrote:
>> Takashi Iwai wrote:
>>> [...]
>>> In the commit mentioned above, we changed the logic to take +25%
>>> frequency as the basis, and it my *reduce* if ep->maxpacksize is lower
>>> than that.
>>>
>>> OTOH, if ep->maxpacksize is sane, we can rely on it rather than the
>>> implicit +25% frequency.  That said, maybe we can check
>>> ep->maxpacksize whether it fits within the expected range, then adapt
>>> it, or take +25% freq as fallback?
>>
>> You are describing how the current code behaves.  The +25% limit _is_
>> what the code takes as the expected range.
>
> Well, the question is what is the "sane" range.  +25% doesn't fit for
> some devices.

The USB audio specification _requires_ that there is as little jitter
as possible.

It's no surprise that some device violates the specification.  But
we don't know what the actual error is; whether we could adjust the
packet size for this particular device only, or increase the limit
for all devices, or use a completely different workaround.

> If maxpacksize fits without +100% as this patch suggests, can we rely
> on it instead?

The packet size affect the following computations, like the number of
packets per URB.  I don't know how bad the effects would be.


Regards,
Clemens

Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize

[Clemens Ladisch]

Jiada Wang wrote:
> On 11/30/2016 11:41 PM, Clemens Ladisch wrote:
>> Jiada Wang wrote:
>>> since commit 57e6dae1087bbaa6b33d3dd8a8e90b63888939a3 the expected 
>>> packetsize is always limited to
>>> nominal + 25%. It was discovered, that some devices
>>
>> Which devices?
>
> It was a LG nexus

So it was the Android audio accessory mode.

>>> have a much higher jitter in used packetsizes than 25%
>>
>> How high?
>
> the nominal packet size was somewhere around 176bytes
> +25% would result in max expected packets to be ~220bytes
> We observed some packets exceeding this size (256byte)

256 bytes per USB frame would correspond to 64 kHz, instead of the
nominal 44.1 kHz.

The audio accessory sample format is fixed, and that mode is no longer
developed, so increasing the limit to +50% would be sufficient to work
around this problem.

I don't know if this is a bug in Google's generic AOA code, or if LG did
some changes; I have not heard any other report so far ...


Regards,
Clemens

Re: [alsa-devel] [PATCH 1/3 v1] ALSA: usb-audio: more tolerant packetsize

[Clemens Ladisch]

Takashi Iwai wrote:
> Clemens Ladisch wrote:
>> Jiada Wang wrote:
>>> since commit 57e6dae1087bbaa6b33d3dd8a8e90b63888939a3 the expected 
>>> packetsize is always limited to
>>> nominal + 25%. It was discovered, that some devices
>>
>> Which devices?
>>
>>> have a much higher jitter in used packetsizes than 25%
>>
>> How high?  (Please note that the USB specification restricts the jitter
>> to at most one frame in consecutive packets.)
>>
>>> which would result in BABBLE condition and dropping of packets.
>>> A better solution is so assume the jitter to be the nominal packetsize
>>
>> This solution is better for this one particular device, but how does it
>> affect normal devices, or the Scarlett 2i4 on EHCI affected?
>
> Actually, which value does this affected device in ep->maxpacksize?
> In the commit mentioned above, we changed the logic to take +25%
> frequency as the basis, and it my *reduce* if ep->maxpacksize is lower
> than that.
>
> OTOH, if ep->maxpacksize is sane, we can rely on it rather than the
> implicit +25% frequency.  That said, maybe we can check
> ep->maxpacksize whether it fits within the expected range, then adapt
> it, or take +25% freq as fallback?

You are describing how the current code behaves.  The +25% limit _is_
what the code takes as the expected range.


I'm wondering if that unknown device just declares a wrong interval value.


Regards,
Clemens

Re: [alsa-devel] [PATCH v2 1/2] ALSA: usb-audio: more tolerant packetsize

[Clemens Ladisch]

Jiada Wang wrote:
> since commit 57e6dae1087b ("ALSA: usb-audio: do not trust too-big
> wMaxPacketSize values"), the expected packetsize is always limited
> to nominal + 25%. It was discovered, that some devices

Android audio accessory

> have a much
> higher jitter in used packetsizes than 25% which would result in BABBLE
> condition and dropping of packets.
> A better solution is so assume the jitter to be the nominal packetsize:
> -one nearly empty packet followed by a almost 150% sized one.
>
> V2: changed to assume max frequency is +50 of nominal packetsize.
>
> Signed-off-by: Andreas Pape <ap...@de.adit-jv.com>
> Signed-off-by: Jiada Wang <jiada_w...@mentor.com>

Acked-by: Clemens Ladisch <clem...@ladisch.de>

> --- a/sound/usb/endpoint.c
> +++ b/sound/usb/endpoint.c
> @@ -632,8 +632,8 @@ static int data_ep_set_params(struct snd_usb_endpoint *ep,
>   ep->stride = frame_bits >> 3;
>   ep->silence_value = pcm_format == SNDRV_PCM_FORMAT_U8 ? 0x80 : 0;
>
> - /* assume max. frequency is 25% higher than nominal */
> - ep->freqmax = ep->freqn + (ep->freqn >> 2);
> + /* assume max. frequency is 50% higher than nominal */
> + ep->freqmax = ep->freqn + (ep->freqn >> 1);
>   /* Round up freqmax to nearest integer in order to calculate maximum
>* packet size, which must represent a whole number of frames.
>* This is accomplished by adding 0x0. before converting the

Re: [PATCH 2/6] hpet: remove unused writeq/readq function definitions

[Clemens Ladisch]

Corentin Labbe wrote:
> On Mon, Mar 27, 2017 at 07:49:34AM +0800, kbuild test robot wrote:
>>drivers//char/hpet.c: In function 'hpet_timer_set_irq':
 drivers//char/hpet.c:207:7: error: implicit declaration of function 
 'readq' [-Werror=implicit-function-declaration]
>
> Wrongly believed that x86 and x86_64 shared writeq/readq.
> Sorry, I will drop this patch
>
> Since the writeq/readq redefined is present in lots of other file, perhaps 
> adding it to i386 could be done.

Just use  instead.


Regards,
Clemens

Re: [PATCH] ALSA: oxygen - Fix snd_oxygen module not loading for some (new?) Xonar DG SI cards.

[Clemens Ladisch]

Eugene Ganeev wrote:
> My Xonar DG SI card is showing up in lspci but no module is loaded for
> it.
>
> The patch just adds a new value with card's PCI ID to oxygen_ids array.

Is the hardware identical?  Do all the inputs and outputs work?

> Signed-off-by: Eugene Ganeev 
> ---
>  sound/pci/oxygen/oxygen.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/sound/pci/oxygen/oxygen.c b/sound/pci/oxygen/oxygen.c
> index ada6c256378e..99ba0354d4cc 100644
> --- a/sound/pci/oxygen/oxygen.c
> +++ b/sound/pci/oxygen/oxygen.c
> @@ -110,6 +110,7 @@ static DEFINE_PCI_DEVICE_TABLE(oxygen_ids) = {
>   { OXYGEN_PCI_SUBID(0x1a58, 0x0910), .driver_data = MODEL_CMEDIA_REF },
>   /* Asus Xonar DG */
>   { OXYGEN_PCI_SUBID(0x1043, 0x8467), .driver_data = MODEL_XONAR_DG },
> + { OXYGEN_PCI_SUBID(0x1043, 0x855e), .driver_data = MODEL_XONAR_DG },

Please add the correct name to the names[] array.


Regards.
Clemens

Re: [PATCH v2 5/6] hpet: removing unused variable m in hpet_interrupt

[Clemens Ladisch]

Corentin Labbe wrote:
> This patch fix the following warning:
> drivers/char/hpet.c:146:17: attention : variable ‘m’ set but not used 
> [-Wunused-but-set-variable]
> by removing the unused variable m in hpet_interrupt

This patch might silence the warning, but it leaves the bug that
actually caused the warning.

As far as I can see, the computation of "base" should use "m".

But the entire algorithm is completely bogus because it does not
actually remove the race condition; the counter is likely to have
advanced beyond the "mc" value when the new comparator value is
written.  Also see arch/x86/kernel/hpet.c for how hpet_next_event()
handles this.

And why a non-periodic timer should generate periodic interrupts is
another question.

And nobody uses this crap.
So I'm really not sure what to do about this ...


Regards,
Clemens

Re: [PATCH v2] usb: core: Warn if an URB's transfer_buffer is on stack

[Clemens Ladisch]

Florian Fainelli wrote:
> We see a large number of fixes to several drivers to remove the usage of
> on-stack buffers feeding into USB transfer functions. Make it easier to spot
> the offenders by adding a warning in usb_hcd_map_urb_for_dma() checking that
> urb->transfer_buffer is not a stack object.

This description is incomplete.

> + } else if (object_is_on_stack(urb->transfer_buffer)) {
> + WARN_ONCE(1, "transfer buffer is on stack\n");
> + ret = -EAGAIN;
>   } else {
>   urb->transfer_dma = dma_map_single(

Not only is there a warning, but the check also forces all those URBs
to abort with an error.

Well, that makes it even easier to spot the offenders ...


Regards,
Clemens

Re: [PATCH v1] hpet: Make cmd parameter of hpet_ioctl_common() unsigned

[Clemens Ladisch]

Matthias Kaehlcke wrote:
> The value passed by the two callers of the function is unsigned anyway.

Indeed; and those are just simple wrappers.

> Making the parameter unsigned fixes the following warning when building
> with clang:
>
> drivers/char/hpet.c:588:7: error: overflow converting case value to switch 
> condition type (2149083139 to 18446744071563667459) [-Werror,-Wswitch]
> case HPET_INFO:
>  ^
> include/uapi/linux/hpet.h:18:19: note: expanded from macro 'HPET_INFO'
> ^
> include/uapi/asm-generic/ioctl.h:77:28: note: expanded from macro '_IOR'
> ^
> include/uapi/asm-generic/ioctl.h:66:2: note: expanded from macro '_IOC'
> (((dir)  << _IOC_DIRSHIFT) | \
>
> Signed-off-by: Matthias Kaehlcke <m...@chromium.org>

Acked-by: Clemens Ladisch <clem...@ladisch.de>

> ---
>  drivers/char/hpet.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
> index 20b32bb8c2af..0d633b76c29e 100644
> --- a/drivers/char/hpet.c
> +++ b/drivers/char/hpet.c
> @@ -574,7 +574,7 @@ static inline unsigned long hpet_time_div(struct hpets 
> *hpets,
>  }
>
>  static int
> -hpet_ioctl_common(struct hpet_dev *devp, int cmd, unsigned long arg,
> +hpet_ioctl_common(struct hpet_dev *devp, unsigned int cmd, unsigned long arg,
> struct hpet_info *info)
>  {
>   struct hpet_timer __iomem *timer;

Re: [PATCH 18/18] ALSA: opl4: Move inline before return type

[Clemens Ladisch]

Joe Perches wrote:
> Make the code like the rest of the kernel.
>
> Signed-off-by: Joe Perches <j...@perches.com>

Acked-by: Clemens Ladisch <clem...@ladisch.de>

> ---
>  sound/drivers/opl4/opl4_lib.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/drivers/opl4/opl4_lib.c b/sound/drivers/opl4/opl4_lib.c
> index bc345d564f8d..db76a5bf2bd2 100644
> --- a/sound/drivers/opl4/opl4_lib.c
> +++ b/sound/drivers/opl4/opl4_lib.c
> @@ -29,7 +29,7 @@ MODULE_AUTHOR("Clemens Ladisch <clem...@ladisch.de>");
>  MODULE_DESCRIPTION("OPL4 driver");
>  MODULE_LICENSE("GPL");
>
> -static void inline snd_opl4_wait(struct snd_opl4 *opl4)
> +static inline void snd_opl4_wait(struct snd_opl4 *opl4)
>  {
>   int timeout = 10;
>   while ((inb(opl4->fm_port) & OPL4_STATUS_BUSY) && --timeout > 0)

Re: [alsa-devel] [PATCH 08/11] ALSA: vsnd: Add timer for period interrupt emulation

[Clemens Ladisch]

Oleksandr Andrushchenko wrote:
> On 08/07/2017 01:27 PM, Clemens Ladisch wrote:
>> You have to implement period interrupts (and the .pointer callback)
>> based on when the samples are actually moved from/to the backend.
>
> Do you think I can implement this in a slightly different way,
> without a timer at all, by updating
> substream->runtime->hw_ptr_base explicitly in the frontend driver?

As far as I am aware, hw_ptr_base is an internal field that drivers
are not supposed to change.

Just use your own variable, and return it from the .pointer callback.

> So, that way, whenever I get an ack/response from the backend that it has
> successfully played the buffer

That response should come after every period.

How does that interface work?  Is it possible to change the period size,
or at least to detect what it is?


Regards,
Clemens

Re: [alsa-devel] [PATCH 08/11] ALSA: vsnd: Add timer for period interrupt emulation

[Clemens Ladisch]

Oleksandr Andrushchenko wrote:
> On 08/07/2017 04:11 PM, Clemens Ladisch wrote:
>> How does that interface work?
>
> For the buffer received in .copy_user/.copy_kernel we send
> a request to the backend and get response back (async) when it has copied
> the bytes into HW/mixer/etc, so the buffer at frontend side can be reused.

So if the frontend sends too many (too large) requests, does the
backend wait until there is enough free space in the buffer before
it does the actual copying and then acks?

If yes, then these acks can be used as interrupts.  (You still
have to count frames, and call snd_pcm_period_elapsed() exactly
when a period boundary was reached or crossed.)

Splitting a large read/write into smaller requests to the backend
would improve the granularity of the known stream position.

The overall latency would be the sum of the sizes of the frontend
and backend buffers.


Why is the protocol designed this way?  Wasn't the goal to expose
some 'real' sound card?


Regards,
Clemens

Re: [alsa-devel] [PATCH 08/11] ALSA: vsnd: Add timer for period interrupt emulation

[Clemens Ladisch]

Oleksandr Andrushchenko wrote:
> Front sound driver has no real interrupts, so
> playback/capture period passed interrupt needs to be emulated:
> this is done via timer. Add required timer operations,
> this is based on sound/drivers/dummy.c.

A 'real' sound card use the interrupt to synchronize the stream position
between the hardware and the driver.  The hardware triggers an interrupt
immediately after a period has been completely read (for playback) from
the ring buffer by the DMA unit; this tells the driver that it is now
again allowed to write to that part of the buffer.

The dummy driver has no hardware that accesses the buffer, so the period
interrupts are not synchronized to anything.  This is not a suitable
implementation when the samples are actually used.

If you issue interrupts based on the system timer, the position reported
by the .pointer callback and the position where the hardware (backend)
actually accesses the buffer will diverge, which will eventually corrupt
data.

You have to implement period interrupts (and the .pointer callback)
based on when the samples are actually moved from/to the backend.


Regards,
Clemens

Re: [alsa-devel] [PATCH] ALSA: USB-MIDI: Use common error handling code in __snd_usbmidi_create()

[Clemens Ladisch]

SF Markus Elfring wrote:
> Add jump targets so that a bit of exception handling can be better reused
> at the end of this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>

Acked-by: Clemens Ladisch <clem...@ladisch.de>

> ---
>  sound/usb/midi.c | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/sound/usb/midi.c b/sound/usb/midi.c
> index a35f41467237..bd9d02268724 100644
> --- a/sound/usb/midi.c
> +++ b/sound/usb/midi.c
> @@ -2435,10 +2435,8 @@ int __snd_usbmidi_create(struct snd_card *card,
>   err = -ENXIO;
>   break;
>   }
> - if (err < 0) {
> - kfree(umidi);
> - return err;
> - }
> + if (err < 0)
> + goto free_midi;
>
>   /* create rawmidi device */
>   out_ports = 0;
> @@ -2448,23 +2446,25 @@ int __snd_usbmidi_create(struct snd_card *card,
>   in_ports += hweight16(endpoints[i].in_cables);
>   }
>   err = snd_usbmidi_create_rawmidi(umidi, out_ports, in_ports);
> - if (err < 0) {
> - kfree(umidi);
> - return err;
> - }
> + if (err < 0)
> + goto free_midi;
>
>   /* create endpoint/port structures */
>   if (quirk && quirk->type == QUIRK_MIDI_MIDIMAN)
>   err = snd_usbmidi_create_endpoints_midiman(umidi, 
> [0]);
>   else
>   err = snd_usbmidi_create_endpoints(umidi, endpoints);
> - if (err < 0) {
> - return err;
> - }
> + if (err < 0)
> + goto exit;
>
>   usb_autopm_get_interface_no_resume(umidi->iface);
>
>   list_add_tail(>list, midi_list);
>   return 0;
> +
> +free_midi:
> + kfree(umidi);
> +exit:
> + return err;
>  }
>  EXPORT_SYMBOL(__snd_usbmidi_create);
>

Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

[Clemens Ladisch]

Randy Dunlap wrote:
> On 05/12/17 19:30, PGNet Dev wrote:
>>  dmesg | grep -i hpet
>>  [8.491738] hpet_acpi_add: no address or irqs in _CRS
>
> Above line marks a big failure. 
> ^^^
>
>> Disassembling the firmware acpi tables
>>
>>  cat /sys/firmware/acpi/tables/HPET > /var/tmp/hpet.out
>>  iasl -d /var/tmp/hpet.out

That table is not used by hpet_acpi_add; you have to check for the device
that mentions "PNP0103" in the DSDT table.

But anyway, as far as I can tell from my own machine, the _CRS in the
DSDT table never lists the HPET interrupts, and the HPET registration is
always done by hpet_reserve_platform_timers() in arch/x86/kernel/hpet.c.
Try adding logging to hpet_late_init() to find out why it aborts.


Regards,
Clemens

Re: [alsa-devel] [PATCH] ALSA: oxygen: Xonar DG(X): make model_xonar_dg const

[Clemens Ladisch]

Bhumika Goyal wrote:
> Make this const as it not modified anywhere. It is only used during a
> copy operation. Also, add const to the declaration in header.
>
> Signed-off-by: Bhumika Goyal <bhumi...@gmail.com>

Acked-by: Clemens Ladisch <clem...@ladisch.de>

> ---
>  sound/pci/oxygen/xonar_dg.h   | 2 +-
>  sound/pci/oxygen/xonar_dg_mixer.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/sound/pci/oxygen/xonar_dg.h b/sound/pci/oxygen/xonar_dg.h
> index d461df3..5a07cda 100644
> --- a/sound/pci/oxygen/xonar_dg.h
> +++ b/sound/pci/oxygen/xonar_dg.h
> @@ -51,6 +51,6 @@ void dump_cs4245_registers(struct oxygen *chip,
>  void dg_resume(struct oxygen *chip);
>  void dg_cleanup(struct oxygen *chip);
>
> -extern struct oxygen_model model_xonar_dg;
> +extern const struct oxygen_model model_xonar_dg;
>
>  #endif
> diff --git a/sound/pci/oxygen/xonar_dg_mixer.c 
> b/sound/pci/oxygen/xonar_dg_mixer.c
> index b885dac..d22fbe8 100644
> --- a/sound/pci/oxygen/xonar_dg_mixer.c
> +++ b/sound/pci/oxygen/xonar_dg_mixer.c
> @@ -449,7 +449,7 @@ static int dg_mixer_init(struct oxygen *chip)
>   return 0;
>  }
>
> -struct oxygen_model model_xonar_dg = {
> +const struct oxygen_model model_xonar_dg = {
>   .longname = "C-Media Oxygen HD Audio",
>   .chip = "CMI8786",
>   .init = dg_init,

Re: [PATCH] hwmon: (k10temp) Add support for family 17h

[Clemens Ladisch]

Guenter Roeck wrote:
> Add support for temperature sensors on Family 17h (Ryzen) processors.
>
> Signed-off-by: Guenter Roeck 
> ---
> Some of this is guesswork, but afaics it is working. No idea if there
> is a better way to determine the temperature offset.

The reported value is not an absolute temperature on any CPU.

As far as I know, the offset is not guaranteed to be fixed for any model,
i.e., it would be pointless to apply the offset observed on one specific
chip.

> @@ -25,6 +25,10 @@
>  #include 
>  #include 
>
> +#ifndef PCI_DEVICE_ID_AMD_17H_DF_F3
> +#define PCI_DEVICE_ID_AMD_17H_DF_F3  0x1463
> +#endif
> +

Please move this down to the other symbols.


Regards,
Clemens

Re: [alsa-devel] [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver

[Clemens Ladisch]

Oleksandr Andrushchenko wrote:
>>> We understand that emulated interrupt on the frontend side is completely not
>>> acceptable

Allow me to expand on that:  Proper synchronization requires that the
exact position is communicated, not estimated.  Just because the nominal
rate of the stream is known does not imply that you know the actual rate.
Forget for the moment that there even is a nominal rate; assume that it
works like, e.g., a storage controller, and that you can know that a DMA
buffer was consumed by the device only after it has told you.

It's possible and likely that there is a latency when reporting the
stream position, but that is still better than guessing what the DMA
is doing.  (You would never just try to guess when writing data to
disk, would you?)

>>> and definitely we need to provide some feedback mechanism from
>>> Dom0 to DomU.
>>>
>>> In our case it is technically impossible to provide precise period interrupt
>>> (mostly because our backend is a user space application).

As far as I can see, all audio APIs (ALSA, PulseAudio, etc.) have poll()
or callbacks or similar mechanisms to inform you when new data can be
written, and always allow to query the current position.

> [...]
> ok, so the main concern here is that we cannot properly synchronize Dom0-DomU.
> If we put this apart for a second are there any other concerns on having ALSA
> frontend driver? If not, can we have the driver with timer implementation 
> upstreamed
> as experimental until we have some acceptable synchronization solution?
> This will allow broader audience to try and feel the solution and probably 
> contribute?

I doubt that the driver architecture will stay completely the same, so I
do not think that this experimental driver would demonstrate how the
solution would feel.

As the first step, I would suggest creating a driver with proper
synchronization, even if it has high latency.  Reducing the latency
would then be 'just' an optimization.


Regards,
Clemens

Re: [PATCH] hwmon: (k10temp) Add support for family 17h

[Clemens Ladisch]

Guenter Roeck wrote:
> On Tue, Sep 05, 2017 at 04:12:07PM +0200, Clemens Ladisch wrote:
>> Guenter Roeck wrote:
>>> What we should do then, as we did for coretemp, would be to collect the 
>>> various
>>> temperature offsets (and temperature limits, for that matter) and apply 
>>> per-CPU
>>> adjustments. Are the offsets documented somewhere ?
>>
>> AMD says:
>>  "Tctl is the processor temperature control value, used by the platform to
>>   control cooling systems. Tctl is a non-physical temperature on an
>>   arbitrary scale measured in degrees. It does _not_ represent an actual
>>   physical temperature like die or case temperature. Instead, it specifies
>>   the processor temperature relative to the point at which the system must
>>   supply the maximum cooling for the processor's specified maximum case
>>   temperature and maximum thermal power dissipation."
>
> Pretty much the same as Intel. That doesn't mean we should not (try to) report
> the real temperature as good as we can, as at least most of the BIOSes do,

AFAIK the BIOSes use the thermal diode (with external circuitry) for that.

> and as all the Windows tools do, and as users expect us to do.
>
> Do we really have to argue about this ?

Looking at coretemp, this is going to be a maintenance nightmare.

Oh well.  If you insist, please add a proper chip-to-offset database, and
apply the offset to all four values.


Regards,
Clemens

Re: [PATCH] hwmon: (k10temp) Add support for family 17h

[Clemens Ladisch]

Guenter Roeck wrote:
> On 09/04/2017 11:47 PM, Clemens Ladisch wrote:
>> Guenter Roeck wrote:
>>> Some of this is guesswork, but afaics it is working. No idea if there
>>> is a better way to determine the temperature offset.
>>
>> The reported value is not an absolute temperature on any CPU.
>>
>> As far as I know, the offset is not guaranteed to be fixed for any model,
>> i.e., it would be pointless to apply the offset observed on one specific
>> chip.
>
> What we should do then, as we did for coretemp, would be to collect the 
> various
> temperature offsets (and temperature limits, for that matter) and apply 
> per-CPU
> adjustments. Are the offsets documented somewhere ?

AMD says:
 "Tctl is the processor temperature control value, used by the platform to
  control cooling systems. Tctl is a non-physical temperature on an
  arbitrary scale measured in degrees. It does _not_ represent an actual
  physical temperature like die or case temperature. Instead, it specifies
  the processor temperature relative to the point at which the system must
  supply the maximum cooling for the processor's specified maximum case
  temperature and maximum thermal power dissipation."

(That point is defined as 70.)


Regards,
Clemens

Re: [alsa-devel] [PATCH] opl3: Fix a possible sleep-in-atomic bug in snd_opl3_find_patch

[Clemens Ladisch]

Jia-Ju Bai wrote:
> The driver may sleep under a spinlock, and the function call path is:
> snd_opl3_note_on (acquire the spinlock)
>   snd_opl3_find_patch
> kzalloc(GFP_KERNEL) --> may sleep

This call path is not possible because create_patch is not set.


Regards,
Clemens

Re: [PATCH] firewire-ohci: work around oversized DMA reads on JMicron controllers

[Clemens Ladisch]

Hector Martin wrote:
> At least some JMicron controllers issue buggy oversized DMA reads when
> fetching context descriptors, always fetching 0x20 bytes at once for
> descriptors which are only 0x10 bytes long. This is often harmless, but
> can cause page faults on modern systems with IOMMUs:
>
> DMAR: [DMA Read] Request device [05:00.0] fault addr fff56000 [fault reason 
> 06] PTE Read access is not set
> firewire_ohci :05:00.0: DMA context IT0 has stopped, error code: 
> evt_descriptor_read
>
> This works around the problem by always leaving 0x10 padding bytes at
> the end of descriptor buffer pages, which should be harmless to do
> unconditionally for controllers in case others have the same behavior.
>
> Signed-off-by: Hector Martin <mar...@marcan.st>

Reviewed-by: Clemens Ladisch <clem...@ladisch.de>

> ---
>  drivers/firewire/ohci.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c
> index 8bf89267dc25..d731b413cb2c 100644
> --- a/drivers/firewire/ohci.c
> +++ b/drivers/firewire/ohci.c
> @@ -1130,7 +1130,13 @@ static int context_add_buffer(struct context *ctx)
>   return -ENOMEM;
>
>   offset = (void *)>buffer - (void *)desc;
> - desc->buffer_size = PAGE_SIZE - offset;
> + /*
> +  * Some controllers, like JMicron ones, always issue 0x20-byte DMA reads
> +  * for descriptors, even 0x10-byte ones. This can cause page faults when
> +  * an IOMMU is in use and the oversized read crosses a page boundary.
> +  * Work around this by always leaving at least 0x10 bytes of padding.
> +  */
> + desc->buffer_size = PAGE_SIZE - offset - 0x10;
>   desc->buffer_bus = bus_addr + offset;
>   desc->used = 0;
>

Re: [PATCH 42/59] sysctl: Remove sys_sysctl support from the hpet timer driver.

[Clemens Ladisch]

Eric W. Biederman wrote:
> From: Eric W. Biederman <[EMAIL PROTECTED]> - unquoted
> 
> In the binary sysctl interface the hpet driver was claiming to
> be the cdrom driver.  This is a no-no so remove support for the
> binary interface.
> 
> Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>

Acked-by: Clemens Ladisch <[EMAIL PROTECTED]>

> ---
>  drivers/char/hpet.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
> index 20dc3be..81be1db 100644
> --- a/drivers/char/hpet.c
> +++ b/drivers/char/hpet.c
> @@ -703,7 +703,7 @@ int hpet_control(struct hpet_task *tp, unsigned int
> cmd, unsigned long arg)
>  
>  static ctl_table hpet_table[] = {
>   {
> -.ctl_name = 1,
> +.ctl_name = CTL_UNNUMBERED,
>.procname = "max-user-freq",
>.data = _max_freq,
>.maxlen = sizeof(int),
> @@ -715,7 +715,7 @@ static ctl_table hpet_table[] = {
>  
>  static ctl_table hpet_root[] = {
>   {
> -.ctl_name = 1,
> +.ctl_name = CTL_UNNUMBERED,
>.procname = "hpet",
>.maxlen = 0,
>.mode = 0555,
> -- 
> 1.4.4.1.g278f
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/6] Convert all tasklets to workqueues

[Clemens Ladisch]

Ingo Molnar wrote:

so how about the following, different approach: anyone who has a tasklet
in any performance-sensitive codepath, please yell now.


ALSA uses quite a few tasklets in the framework and in several  
drivers.  Since we

care very much about low latency, many places use tasklet_hi_*.

It would be possible to convert to some GENERIC_SOFTIRQ mechanism, but  
then we'd

want to use a softirq that has higher priority than the 'standard' generic
softirq, similar to HI_SOFTIRQ vs. TASKLET_SOFTIRQ.

BTW: Is there a reason why HRTIMER_SOFTIRQ is the lowest-priority  
softirq instead

of being near TIMER_SOFTIRQ?


Regards,
Clemens

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

Re: MOTU Fastlane USB MIDI interface

[Clemens Ladisch]

David Griffith wrote:

Does anyone here have or can borrow a MOTU Fastlane USB MIDI interface?
I'm having a nasty time trying to nail down what's going wrong.  It seems
that for kernels 2.6.17 and earlier, MIDI works fine through this
interface.  After that, it doesn't.


What do you mean with "doesn't work"?  Does the kernel detect it?   
Does it appear

in /proc/asound/cards?  What happens if you try to use it?


Regards,
Clemens

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

Re: MOTU Fastlane USB MIDI interface

[Clemens Ladisch]

David Griffith wrote:

Checking further, I've never been able to
get midi to work with kernels 2.6.18 and later.


Please try "amidi -d -p virtual" and playing a .mid file to this port with
aplaymidi.


Regards,
Clemens

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

Re: MOTU Fastlane USB MIDI interface

[Clemens Ladisch]

David Griffith wrote:
> On Thu, 16 Aug 2007, Clemens Ladisch wrote:
> > Please try "amidi -d -p virtual" and playing a .mid file to this port with
> > aplaymidi.
> 
> $ aplaymidi -p "virtual" castle2.mid
> Invalid port virtual - No such file or directory

Sorry, the name of the correspondig sequencer port is different,
probably "128:0"; see the output of "aplaymidi -l".


Regards,
Clemens
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: MOTU Fastlane USB MIDI interface

[Clemens Ladisch]

David Griffith wrote:
> On Fri, 17 Aug 2007, Clemens Ladisch wrote:
> > David Griffith wrote:
> > > On Thu, 16 Aug 2007, Clemens Ladisch wrote:
> > > > Please try "amidi -d -p virtual" and playing a .mid file to this port 
> > > > with
> > > > aplaymidi.
> > >
> > > $ aplaymidi -p "virtual" castle2.mid
> > > Invalid port virtual - No such file or directory
> >
> > Sorry, the name of the correspondig sequencer port is different,
> > probably "128:0"; see the output of "aplaymidi -l".
> 
> $ aplaymidi -l
>  PortClient name  Port name
>  14:0Midi Through Midi Through Port-0
>  16:0Ensoniq AudioPCI ES1371
>  20:0Fastlane Fastlane MIDI A
>  20:1Fastlane Fastlane MIDI B
> 
> $ aplaymidi -p 20:0 casablan.mid
> 
> Nothing is written to the Fastlane.  No lights.  Nothing.

Please run "amidi -d -p virtual" and then play to the virtual port
created by amidi, to see if MIDI playback works even without hardware.


Regards,
Clemens
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: MOTU Fastlane USB MIDI interface

[Clemens Ladisch]

David Griffith wrote:

On Mon, 20 Aug 2007, Clemens Ladisch wrote:

David Griffith wrote:
> $ aplaymidi -p 20:0 casablan.mid
>
> Nothing is written to the Fastlane.  No lights.  Nothing.

Please run "amidi -d -p virtual" and then play to the virtual port
created by amidi, to see if MIDI playback works even without hardware.


$ aplaymidi -p 128:0 casablan.mid

At this point, MIDI data flew by in the xterm in which amidi was running.


Hmmm, it's either the driver or device.

Please uncomment the "#define DUMP_PACKETS" in line 58 of sound/usb/usbmidi.c
and recompile the driver.  All MIDI data should then be visible in the system
log.


Regards,
Clemens

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

Re: "double" hpet clocksource && hard freeze [bisected]

[Clemens Ladisch]

Luck, Tony wrote:

[...] Given that the hang went away when you applied the earlier patch, I
conclude that the drivers/char/hpet.c code is the one that got selected when
you had two "hpet" entries ... and that there is something wrong with that
code that doesn't work right on x86_64.


Apparently, the 'generic' code was just copied from ia64 and assumes that the
timer is 64 bits.  This is not true with hardware from VIA (even on x86_64).

This patch should make it work (although I'd prefer to set the mask  
dynamically

according to the hardware caps).

--- a/drivers/char/hpet.c   Tue Aug 28 09:42:22 2007
+++ b/drivers/char/hpet.c   Tue Aug 28 10:16:54 2007
@@ -73,7 +73,7 @@
 .name   = "hpet",
 .rating = 250,
 .read   = read_hpet,
-.mask   = CLOCKSOURCE_MASK(64),
+.mask   = CLOCKSOURCE_MASK(32),
 .mult   = 0, /*to be caluclated*/
 .shift  = 10,
 .flags  = CLOCK_SOURCE_IS_CONTINUOUS,


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

Re: drivers/usb/misc/emi*.c have the biggest data objects in the whole tree

[Clemens Ladisch]

Denys Vlasenko wrote:

Hi Tapio,

You are the author of these files. Are you still maintaining them?


His newer email address that I found with Google is dead, too.

These two object files hold the biggest data objects in the whole   
Linux kernel


Basically, these are big arrays of the following structures:

typedef struct _INTEL_HEX_RECORD
{
__u32   length;
__u32   address;
__u32   type;
__u8data[MAX_INTEL_HEX_RECORD_LENGTH];
} INTEL_HEX_RECORD;

I suggest the following optimizations:

Change structure to

typedef struct _INTEL_HEX_RECORD
{
__u8   type;
__u8   length;
__u16   address;
__u8data[MAX_INTEL_HEX_RECORD_LENGTH];
} INTEL_HEX_RECORD __attribute__((__packed__));

Store gzip compressed tables and unpack them at load time.

Declare them const and __initdata.


I have a patch somewhere that moves the firmware code to userspace and changes
the drivers to use request_firmware().


Regards,
Clemens

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

Re: alsa problem

[Clemens Ladisch]

Donn Washburn wrote:
> I am not on the list

Indeed you are not on the alsa-devel list.

> It works some times

What works?  And why would that be a problem?


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

[PATCH] vt: make the default color configurable

[Clemens Ladisch]

The virtual console has (undocumented) module parameters to set the
colors for italic and underlined text, but the default text color was
hardcoded for some reason.  This made it impossible to change the color
for startup messages, or to set the default for new virtual consoles.
Add a module parameter for that, and document the entire bunch.

Any hacker who thinks that a command prompt on a "black screen with
white font" is not supicious enough can now use the kernel parameter
vt.color=10 to get a nice, evil green.

Signed-off-by: Clemens Ladisch 
---
 Documentation/kernel-parameters.txt |   10 ++
 drivers/tty/vt/vt.c |4 +++-
 2 files changed, 13 insertions(+), 1 deletion(-)

Changing the background color looks ugly because the cute penguin logo
is designed for a black background; somebody ought to implement alpha
blending ...

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 15356ac..f6c8b41 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3322,6 +3322,10 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
them quite hard to use for exploits but
might break your system.

+   vt.color=   [VT] Default text color.
+   Format: 0xYX, X = foreground, Y = background.
+   Default: 0x07 = light gray on black.
+
vt.cur_default= [VT] Default cursor shape.
Format: 0xCCBBAA, where AA, BB, and CC are the same as
the parameters of the [?A;B;Cc escape sequence;
@@ -3361,6 +3365,12 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
overridden by individual drivers. 0 will hide
cursors, 1 will display them.

+   vt.italic=  [VT] Default color for italic text; 0-15.
+   Default: 2 = green.
+
+   vt.underline=   [VT] Default color for underlined text; 0-15.
+   Default: 3 = cyan.
+
watchdog timers [HW,WDT] For information on watchdog timers,
see Documentation/watchdog/watchdog-parameters.txt
or other driver-specific files in the
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index c677829..8675719 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -2809,8 +2809,10 @@ static void con_shutdown(struct tty_struct *tty)
console_unlock();
 }

+static int default_color   = 7; /* white */
 static int default_italic_color= 2; // green (ASCII)
 static int default_underline_color = 3; // cyan (ASCII)
+module_param_named(color, default_color, int, S_IRUGO | S_IWUSR);
 module_param_named(italic, default_italic_color, int, S_IRUGO | S_IWUSR);
 module_param_named(underline, default_underline_color, int, S_IRUGO | S_IWUSR);

@@ -2832,7 +2834,7 @@ static void vc_init(struct vc_data *vc, unsigned int rows,
vc->vc_palette[k++] = default_grn[j] ;
vc->vc_palette[k++] = default_blu[j] ;
}
-   vc->vc_def_color   = 0x07;   /* white */
+   vc->vc_def_color   = default_color;
vc->vc_ulcolor = default_underline_color;
vc->vc_itcolor = default_italic_color;
vc->vc_halfcolor   = 0x08;   /* grey */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [alsa-devel] [RFC] revoke(2) and generic handling of things like remove_proc_entry()

[Clemens Ladisch]

Al Viro wrote:
> BTW, snd_card_disconnect() doesn't do anything to existing mappings; smells
> like a bug, and there we do have ones with non-trivial ->mmap().  Could
> ALSA folks comment?

I don't know of any hotplug sound driver that maps memory from a device.
All hotplug buses (PCIe, USB, FireWire) involve DMAing from/to main
memory.

When a sound device is unplugged, sample transfers just stop, but the
buffer itself stays as long as the device node is kept opened.  (In the
case of a capture device, that actually makes sense.)


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

Re: Is __ffs64 supposed to be zero based?

[Clemens Ladisch]

Ben Greear wrote:
> Similarly named methods elsewhere seem to indicate it is supposed to be
> ones-based counting (ie, bit (1<<0) would be considred 'bit 1'.

ffs() is defined to use one-based counting:


__ffs() uses zero-based counting.  On gcc, it's likely to be implemented
with__builtin_ctz*(), whose documentation says:
| Returns the number of trailing 0-bits in x, starting at the least
| significant bit position.


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