1. 24 5月, 2019 7 次提交
  2. 23 5月, 2019 6 次提交
  3. 22 5月, 2019 4 次提交
  4. 21 5月, 2019 4 次提交
  5. 18 3月, 2019 1 次提交
    • T
      ALSA: firewire-lib: use 8 byte header for IR context to get isochronous cycle · cc4f8e91
      Takashi Sakamoto 提交于
      In kernel API of Linux FireWire subsystem, handlers of isochronous
      receive (IR) context can get context headers as an argument of
      callback. When 4 byte header is used, the context header includes
      isochronous packet header for each packet. When 8 byte header is
      used, it includes isochronous cycle as well.
      
      ALSA IEC 61883-1/6 engine uses 4 byte header, and computes isochronous
      cycle from the cycle of interrupt. The usage of 8 byte header can
      obsolete the computation.
      
      Furthermore, this change works well for a case that a series of
      packet in one interrupt includes skipped isochronous cycle,
      
      This commit uses 8 byte header to handle isochronous cycle.
      Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      cc4f8e91
  6. 16 12月, 2018 1 次提交
  7. 30 10月, 2018 1 次提交
    • T
      ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size · 826b5de9
      Takashi Sakamoto 提交于
      In a former commit, PCM constraint based on LCM of SYT_INTERVAL was
      obsoleted with PCM rule. However, the new PCM rule brings -EINVAL in
      some cases that max/min values of size of buffer/period is not
      multiples of one of values of SYT_INTERVAL. For example, pulseaudio
      always fail to configure PCM substream.
      
      This commit changes strategy for the PCM rule. Although the buggy rules
      had a single dependency (rate from period, period from rate, rate from
      buffer, buffer from rate), a revised rule has double dependencies
      (period from period/rate, buffer from buffer/rate). A step of value is
      calculated with table of SYT_INTERVAL and list of available rates. This
      prevents interval template which brings -EINVAL to a call of
      snd_interval_refine().
      
      Fixes: 59502295('ALSA: firewire-lib: add PCM rules to obsolete PCM constraints based on LCM of SYT_INTERVAL')
      Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      826b5de9
  8. 02 10月, 2018 1 次提交
    • T
      ALSA: firewire-lib: add PCM rules to obsolete PCM constraints based on LCM of SYT_INTERVAL · 59502295
      Takashi Sakamoto 提交于
      In blocking mode of IEC 61883-1/6, when one isochronous packet includes
      data for events, the data is for the same number of events as
      SYT_INTERVAL decided according to sampling transmission frequency (SFC).
      
      IEC 61883-1/6 engine of ALSA firewire stack applies constraints of
      period and buffer size of PCM intermediate buffer of PCM substream.
      At present, this constraint is designed to round the size up/down to
      32 frames. This value comes from the least common multiple (LCM) of
      SYT_INTERVAL. Although this looks to work well, in lower sampling
      rate, applications are not allowed to set size of period quite near
      period time constraint (at present 5 msec per period).
      
      This commit adds PCM rules for period/buffer size and rate to obsoletes
      the constraints based on LCM.
      Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      59502295
  9. 29 4月, 2018 1 次提交
    • T
      ALSA: dice: fix kernel NULL pointer dereference due to invalid calculation for array index · 52759c09
      Takashi Sakamoto 提交于
      At a commit f91c9d76 ('ALSA: firewire-lib: cache maximum length of
      payload to reduce function calls'), maximum size of payload for tx
      isochronous packet is cached to reduce the number of function calls.
      
      This cache was programmed to updated at a first callback of ohci1394 IR
      context. However, the maximum size is required to queueing packets before
      starting the isochronous context.
      
      As a result, the cached value is reused to queue packets in next time to
      starting the isochronous context. Then the cache is updated in a first
      callback of the isochronous context. This can cause kernel NULL pointer
      dereference in a below call graph:
      
      (sound/firewire/amdtp-stream.c)
      amdtp_stream_start()
      ->queue_in_packet()
        ->queue_packet()
          (drivers/firewire/core-iso.c)
          ->fw_iso_context_queue()
            ->struct fw_card_driver.queue_iso()
            (drivers/firewire/ohci.c)
            = ohci_queue_iso()
              ->queue_iso_packet_per_buffer()
                buffer->pages[page]
      
      The issued dereference occurs in a case that:
       - target unit supports different stream formats for sampling transmission
         frequency.
       - maximum length of payload for tx stream in a first trial is bigger
         than the length in a second trial.
      
      In this case, correct number of pages are allocated for DMA and the 'pages'
      array has enough elements, while index of the element is wrongly calculated
      according to the old value of length of payload in a call of
      'queue_in_packet()'. Then it causes the issue.
      
      This commit fixes the critical bug. This affects all of drivers in ALSA
      firewire stack in Linux kernel v4.12 or later.
      
      [12665.302360] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
      [12665.302415] IP: ohci_queue_iso+0x47c/0x800 [firewire_ohci]
      [12665.302439] PGD 0
      [12665.302440] P4D 0
      [12665.302450]
      [12665.302470] Oops: 0000 [#1] SMP PTI
      [12665.302487] Modules linked in: ...
      [12665.303096] CPU: 1 PID: 12760 Comm: jackd Tainted: P           OE   4.13.0-38-generic #43-Ubuntu
      [12665.303154] Hardware name:                  /DH77DF, BIOS KCH7710H.86A.0069.2012.0224.1825 02/24/2012
      [12665.303215] task: ffff9ce87da2ae80 task.stack: ffffb5b8823d0000
      [12665.303258] RIP: 0010:ohci_queue_iso+0x47c/0x800 [firewire_ohci]
      [12665.303301] RSP: 0018:ffffb5b8823d3ab8 EFLAGS: 00010086
      [12665.303337] RAX: ffff9ce4f4876930 RBX: 0000000000000008 RCX: ffff9ce88a3955e0
      [12665.303384] RDX: 0000000000000000 RSI: 0000000034877f00 RDI: 0000000000000000
      [12665.303427] RBP: ffffb5b8823d3b68 R08: ffff9ce8ccb390a0 R09: ffff9ce877639ab0
      [12665.303475] R10: 0000000000000108 R11: 0000000000000000 R12: 0000000000000003
      [12665.303513] R13: 0000000000000000 R14: ffff9ce4f4876950 R15: 0000000000000000
      [12665.303554] FS:  00007f2ec467f8c0(0000) GS:ffff9ce8df280000(0000) knlGS:0000000000000000
      [12665.303600] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [12665.303633] CR2: 0000000000000030 CR3: 00000002dcf90004 CR4: 00000000000606e0
      [12665.303674] Call Trace:
      [12665.303698]  fw_iso_context_queue+0x18/0x20 [firewire_core]
      [12665.303735]  queue_packet+0x88/0xe0 [snd_firewire_lib]
      [12665.303770]  amdtp_stream_start+0x19b/0x270 [snd_firewire_lib]
      [12665.303811]  start_streams+0x276/0x3c0 [snd_dice]
      [12665.303840]  snd_dice_stream_start_duplex+0x1bf/0x480 [snd_dice]
      [12665.303882]  ? vma_gap_callbacks_rotate+0x1e/0x30
      [12665.303914]  ? __rb_insert_augmented+0xab/0x240
      [12665.303936]  capture_prepare+0x3c/0x70 [snd_dice]
      [12665.303961]  snd_pcm_do_prepare+0x1d/0x30 [snd_pcm]
      [12665.303985]  snd_pcm_action_single+0x3b/0x90 [snd_pcm]
      [12665.304009]  snd_pcm_action_nonatomic+0x68/0x70 [snd_pcm]
      [12665.304035]  snd_pcm_prepare+0x68/0x90 [snd_pcm]
      [12665.304058]  snd_pcm_common_ioctl1+0x4c0/0x940 [snd_pcm]
      [12665.304083]  snd_pcm_capture_ioctl1+0x19b/0x250 [snd_pcm]
      [12665.304108]  snd_pcm_capture_ioctl+0x27/0x40 [snd_pcm]
      [12665.304131]  do_vfs_ioctl+0xa8/0x630
      [12665.304148]  ? entry_SYSCALL_64_after_hwframe+0xe9/0x139
      [12665.304172]  ? entry_SYSCALL_64_after_hwframe+0xe2/0x139
      [12665.304195]  ? entry_SYSCALL_64_after_hwframe+0xdb/0x139
      [12665.304218]  ? entry_SYSCALL_64_after_hwframe+0xd4/0x139
      [12665.304242]  ? entry_SYSCALL_64_after_hwframe+0xcd/0x139
      [12665.304265]  ? entry_SYSCALL_64_after_hwframe+0xc6/0x139
      [12665.304288]  ? entry_SYSCALL_64_after_hwframe+0xbf/0x139
      [12665.304312]  ? entry_SYSCALL_64_after_hwframe+0xb8/0x139
      [12665.304335]  ? entry_SYSCALL_64_after_hwframe+0xb1/0x139
      [12665.304358]  SyS_ioctl+0x79/0x90
      [12665.304374]  ? entry_SYSCALL_64_after_hwframe+0x72/0x139
      [12665.304397]  entry_SYSCALL_64_fastpath+0x24/0xab
      [12665.304417] RIP: 0033:0x7f2ec3750ef7
      [12665.304433] RSP: 002b:00007fff99e31388 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      [12665.304465] RAX: ffffffffffffffda RBX: 00007fff99e312f0 RCX: 00007f2ec3750ef7
      [12665.304494] RDX: 0000000000000000 RSI: 0000000000004140 RDI: 0000000000000007
      [12665.304522] RBP: 0000556ebc63fd60 R08: 0000556ebc640560 R09: 0000000000000000
      [12665.304553] R10: 0000000000000001 R11: 0000000000000246 R12: 0000556ebc63fcf0
      [12665.304584] R13: 0000000000000000 R14: 0000000000000007 R15: 0000000000000000
      [12665.304612] Code: 01 00 00 44 89 eb 45 31 ed 45 31 db 66 41 89 1e 66 41 89 5e 0c 66 45 89 5e 0e 49 8b 49 08 49 63 d4 4d 85 c0 49 63 ff 48 8b 14 d1 <48> 8b 72 30 41 8d 14 37 41 89 56 04 48 63 d3 0f 84 ce 00 00 00
      [12665.304713] RIP: ohci_queue_iso+0x47c/0x800 [firewire_ohci] RSP: ffffb5b8823d3ab8
      [12665.304743] CR2: 0000000000000030
      [12665.317701] ---[ end trace 9d55b056dd52a19f ]---
      
      Fixes: f91c9d76 ('ALSA: firewire-lib: cache maximum length of payload to reduce function calls')
      Cc: <stable@vger.kernel.org> # v4.12+
      Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      52759c09
  10. 25 10月, 2017 1 次提交
    • M
      locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns... · 6aa7de05
      Mark Rutland 提交于
      locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()
      
      Please do not apply this to mainline directly, instead please re-run the
      coccinelle script shown below and apply its output.
      
      For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
      preference to ACCESS_ONCE(), and new code is expected to use one of the
      former. So far, there's been no reason to change most existing uses of
      ACCESS_ONCE(), as these aren't harmful, and changing them results in
      churn.
      
      However, for some features, the read/write distinction is critical to
      correct operation. To distinguish these cases, separate read/write
      accessors must be used. This patch migrates (most) remaining
      ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following
      coccinelle script:
      
      ----
      // Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and
      // WRITE_ONCE()
      
      // $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch
      
      virtual patch
      
      @ depends on patch @
      expression E1, E2;
      @@
      
      - ACCESS_ONCE(E1) = E2
      + WRITE_ONCE(E1, E2)
      
      @ depends on patch @
      expression E;
      @@
      
      - ACCESS_ONCE(E)
      + READ_ONCE(E)
      ----
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: davem@davemloft.net
      Cc: linux-arch@vger.kernel.org
      Cc: mpe@ellerman.id.au
      Cc: shuah@kernel.org
      Cc: snitzer@redhat.com
      Cc: thor.thayer@linux.intel.com
      Cc: tj@kernel.org
      Cc: viro@zeniv.linux.org.uk
      Cc: will.deacon@arm.com
      Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      6aa7de05
  11. 19 6月, 2017 1 次提交
    • T
      ALSA: firewire-lib: Fix stall of process context at packet error · 4a9bfafc
      Takashi Sakamoto 提交于
      At Linux v3.5, packet processing can be done in process context of ALSA
      PCM application as well as software IRQ context for OHCI 1394. Below is
      an example of the callgraph (some calls are omitted).
      
      ioctl(2) with e.g. HWSYNC
      (sound/core/pcm_native.c)
      ->snd_pcm_common_ioctl1()
        ->snd_pcm_hwsync()
          ->snd_pcm_stream_lock_irq
          (sound/core/pcm_lib.c)
          ->snd_pcm_update_hw_ptr()
            ->snd_pcm_udpate_hw_ptr0()
              ->struct snd_pcm_ops.pointer()
              (sound/firewire/*)
              = Each handler on drivers in ALSA firewire stack
                (sound/firewire/amdtp-stream.c)
                ->amdtp_stream_pcm_pointer()
                  (drivers/firewire/core-iso.c)
                  ->fw_iso_context_flush_completions()
                    ->struct fw_card_driver.flush_iso_completion()
                    (drivers/firewire/ohci.c)
                    = flush_iso_completions()
                      ->struct fw_iso_context.callback.sc
                      (sound/firewire/amdtp-stream.c)
                      = in_stream_callback() or out_stream_callback()
                        ->...
          ->snd_pcm_stream_unlock_irq
      
      When packet queueing error occurs or detecting invalid packets in
      'in_stream_callback()' or 'out_stream_callback()', 'snd_pcm_stop_xrun()'
      is called on local CPU with disabled IRQ.
      
      (sound/firewire/amdtp-stream.c)
      in_stream_callback() or out_stream_callback()
      ->amdtp_stream_pcm_abort()
        ->snd_pcm_stop_xrun()
          ->snd_pcm_stream_lock_irqsave()
          ->snd_pcm_stop()
          ->snd_pcm_stream_unlock_irqrestore()
      
      The process is stalled on the CPU due to attempt to acquire recursive lock.
      
      [  562.630853] INFO: rcu_sched detected stalls on CPUs/tasks:
      [  562.630861]      2-...: (1 GPs behind) idle=37d/140000000000000/0 softirq=38323/38323 fqs=7140
      [  562.630862]      (detected by 3, t=15002 jiffies, g=21036, c=21035, q=5933)
      [  562.630866] Task dump for CPU 2:
      [  562.630867] alsa-source-OXF R  running task        0  6619      1 0x00000008
      [  562.630870] Call Trace:
      [  562.630876]  ? vt_console_print+0x79/0x3e0
      [  562.630880]  ? msg_print_text+0x9d/0x100
      [  562.630883]  ? up+0x32/0x50
      [  562.630885]  ? irq_work_queue+0x8d/0xa0
      [  562.630886]  ? console_unlock+0x2b6/0x4b0
      [  562.630888]  ? vprintk_emit+0x312/0x4a0
      [  562.630892]  ? dev_vprintk_emit+0xbf/0x230
      [  562.630895]  ? do_sys_poll+0x37a/0x550
      [  562.630897]  ? dev_printk_emit+0x4e/0x70
      [  562.630900]  ? __dev_printk+0x3c/0x80
      [  562.630903]  ? _raw_spin_lock+0x20/0x30
      [  562.630909]  ? snd_pcm_stream_lock+0x31/0x50 [snd_pcm]
      [  562.630914]  ? _snd_pcm_stream_lock_irqsave+0x2e/0x40 [snd_pcm]
      [  562.630918]  ? snd_pcm_stop_xrun+0x16/0x70 [snd_pcm]
      [  562.630922]  ? in_stream_callback+0x3e6/0x450 [snd_firewire_lib]
      [  562.630925]  ? handle_ir_packet_per_buffer+0x8e/0x1a0 [firewire_ohci]
      [  562.630928]  ? ohci_flush_iso_completions+0xa3/0x130 [firewire_ohci]
      [  562.630932]  ? fw_iso_context_flush_completions+0x15/0x20 [firewire_core]
      [  562.630935]  ? amdtp_stream_pcm_pointer+0x2d/0x40 [snd_firewire_lib]
      [  562.630938]  ? pcm_capture_pointer+0x19/0x20 [snd_oxfw]
      [  562.630943]  ? snd_pcm_update_hw_ptr0+0x47/0x3d0 [snd_pcm]
      [  562.630945]  ? poll_select_copy_remaining+0x150/0x150
      [  562.630947]  ? poll_select_copy_remaining+0x150/0x150
      [  562.630952]  ? snd_pcm_update_hw_ptr+0x10/0x20 [snd_pcm]
      [  562.630956]  ? snd_pcm_hwsync+0x45/0xb0 [snd_pcm]
      [  562.630960]  ? snd_pcm_common_ioctl1+0x1ff/0xc90 [snd_pcm]
      [  562.630962]  ? futex_wake+0x90/0x170
      [  562.630966]  ? snd_pcm_capture_ioctl1+0x136/0x260 [snd_pcm]
      [  562.630970]  ? snd_pcm_capture_ioctl+0x27/0x40 [snd_pcm]
      [  562.630972]  ? do_vfs_ioctl+0xa3/0x610
      [  562.630974]  ? vfs_read+0x11b/0x130
      [  562.630976]  ? SyS_ioctl+0x79/0x90
      [  562.630978]  ? entry_SYSCALL_64_fastpath+0x1e/0xad
      
      This commit fixes the above bug. This assumes two cases:
      1. Any error is detected in software IRQ context of OHCI 1394 context.
      In this case, PCM substream should be aborted in packet handler. On the
      other hand, it should not be done in any process context. TO distinguish
      these two context, use 'in_interrupt()' macro.
      2. Any error is detect in process context of ALSA PCM application.
      In this case, PCM substream should not be aborted in packet handler
      because PCM substream lock is acquired. The task to abort PCM substream
      should be done in ALSA PCM core. For this purpose, SNDRV_PCM_POS_XRUN is
      returned at 'struct snd_pcm_ops.pointer()'.
      Suggested-by: NClemens Ladisch <clemens@ladisch.de>
      Fixes: e9148ddd("ALSA: firewire-lib: flush completed packets when reading PCM position")
      Cc: <stable@vger.kernel.org> # 4.9+
      Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      4a9bfafc
  12. 08 6月, 2017 1 次提交
  13. 07 6月, 2017 1 次提交
    • T
      ALSA: firewire: process packets in 'struct snd_pcm_ops.ack' callback · 875becf8
      Takashi Sakamoto 提交于
      In recent commit for ALSA PCM core, some arrangement is done for
      'struct snd_pcm_ops.ack' callback. This is called when appl_ptr is
      explicitly moved in intermediate buffer for PCM frames, except for
      some cases described later.
      
      For drivers in ALSA firewire stack, usage of this callback has a merit to
      reduce latency between time of PCM frame queueing and handling actual
      packets in recent isochronous cycle, because no need to wait for software
      IRQ context from isochronous context of OHCI 1394.
      
      If this works well in a case that mapped page frame is used for the
      intermediate buffer, user process should execute some commands for ioctl(2)
      to tell the number of handled PCM frames in the intermediate buffer just
      after handling them. Therefore, at present, with a combination of below
      conditions, this doesn't work as expected and user process should wait for
      the software IRQ context as usual:
       - when ALSA PCM core judges page frame mapping is available for status
         data (struct snd_pcm_mmap_status) and control data
         (struct snd_pcm_mmap_control).
       - user process handles PCM frames by loop just with 'snd_pcm_mmap_begin()'
         and 'snd_pcm_mmap_commit()'.
       - user process uses PCM hw plugin in alsa-lib to operate I/O without
         'sync_ptr_ioctl' option.
      
      Unfortunately, major use case include these three conditions.
      Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      875becf8
  14. 12 4月, 2017 1 次提交
  15. 11 4月, 2017 1 次提交
  16. 06 4月, 2017 2 次提交
    • T
      ALSA: firewire-lib: add no-header packet processing · 3b196c39
      Takashi Sakamoto 提交于
      As long as investigating Fireface 400, IEC 61883-1/6 is not applied to
      its packet streaming protocol. Remarks of the specific protocol are:
       * Each packet doesn't include CIP headers.
       * 64,0 and 128,0 kHz are supported.
       * The device doesn't necessarily transmit 8,000 packets per second.
       * 0, 1, 2, 3 are used as tag for rx isochronous packets, however 0 is
         used for tx isochronous packets.
      
      On the other hand, there's a common feature. The number of data blocks
      transferred in a second is the same as sampling transmission frequency.
      Current ALSA IEC 61883-1/6 engine already has a method to calculate it and
      this driver can utilize it for rx packets, as well as tx packets.
      
      This commit adds support for the transferring protocol. CIP_NO_HEADERS
      flag is newly added. When this flag is set:
       * Both of 0 (without CIP header) and 1 (with CIP header) are used as tag
         to handle incoming isochronous packet.
       * 0 (without CIP header) is used as tag to transfer outgoing isochronous
         packet.
       * Skip CIP header evaluation.
       * Use unique way to calculate the quadlets of isochronous packet payload.
      
      In ALSA PCM interface, 128.0 kHz is not supported, and the ALSA
      IEC 61883-1/6 engine doesn't support 64.0 kHz. These modes are dropped.
      
      The sequence of rx packet has a remarkable quirk about tag. This will be
      described in later commits.
      Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      3b196c39
    • T
      ALSA: firewire-lib: use the same prototype for functions to handle packet · ff0fb5aa
      Takashi Sakamoto 提交于
      Audio and music units of RME Fireface series use its own protocol for
      isochronous packets to transfer data. This protocol requires ALSA IEC
      61883-1/6 engine to have alternative functions.
      
      This commit is a preparation for the protocol.
      Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      ff0fb5aa
  17. 28 3月, 2017 4 次提交
  18. 05 1月, 2017 1 次提交
    • T
      Revert "ALSA: firewire-lib: change structure member with proper type" · e4f34cf6
      Takashi Sakamoto 提交于
      This reverts commit 6b7e95d1. This commit
      is based on a concern about value of the given parameter. It's expected
      to be ORed value with some enumeration-constants, thus often it can not be
      one of the enumeration-constants. I understood that this is out of
      specification and causes implementation-dependent issues.
      
      In C language specification, enumerated type can be interpreted as an
      integer type, in which all of enumeration-constants in corresponding
      enumerator-list can be stored. Implementations can select one of char,
      signed int and unsigned int as its type, and this selection is
      implementation-dependent.
      
      In GCC, a signed integer is selected when at least one of
      enumeration-constants has negative value, else an unsigned integer is
      selected. This behaviour can be switched by -fshort-enums to short type.
      Anyway, the type can be decided after scanning all of
      enumeration-constants.
      
      Totally, there's no rules to constrain the value of enumerated type to
      be one of enumeration-constants. In short, in enumerated type, decision
      of actual type for the type is the most important and
      enumeration-constants are just used for the decision, thus it's permitted
      to have an integer value in a range of enumeration-constants. In our case,
      actual type for the type is currently deterministic to be either char or
      unsigned int. Under GCC, it's unsigned int.
      Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      e4f34cf6
  19. 03 1月, 2017 1 次提交