urtwn: change slot time via ic_updateslot method (by default it's set to 9us)

[avos]

Test Plan

Tested with RTL8188EU / RTL8188CUS in STA mode.

[adrian]

looks fine!

head/sys/dev/usb/wlan/if_urtwn.c

<sect1 xml:id="security-intro">
     <para>A security vulnerability is all different.  First, it may
       remain unnoticed for years because often it does not cause
       software malfunction.  Second, a malicious party can use it to
       gain unauthorized access to a vulnerable system, to destroy or
       alter sensitive data; and in the worst case the user will not
       even notice the harm caused.  Third, exposing a vulnerable
       system often assists attackers to break into other systems that
       could not be compromised otherwise.  Therefore closing a
-      vulnerability alone is not enough: the audience should be
-      notified of it in most clear and comprehensive manner, which
+      vulnerability alone is not enough: notify the audience
+      of it in most clear and comprehensive manner, which
       will allow to evaluate the danger and take appropriate
       actions.</para>
   </sect1>
 
   <sect1 xml:id="security-fix">
     <title>Fixing Security Vulnerabilities</title>
 
     <para>While on the subject of ports and packages, a security
       vulnerability may initially appear in the original distribution
       or in the port files.  In the former case, the original software
       developer is likely to release a patch or a new version
-      instantly, and you will only need to update the port promptly
+      instantly.  Update the port promptly
       with respect to the author's fix.  If the fix is delayed for
-      some reason, you should either
+      some reason, either
       <link linkend="dads-noinstall">mark the port as
-      <varname>FORBIDDEN</varname></link> or introduce a patch file of
-      your own to the port.  In the case of a vulnerable port, just
-      fix the port as soon as possible.  In either case,
+      <varname>FORBIDDEN</varname></link> or introduce a patch file
+      to the port.  In the case of a vulnerable port, just
+      fix the port as soon as possible.  In either case, follow
       <link linkend="port-upgrading">the standard procedure for
-      submitting your change</link> should be followed unless you have
+      submitting changes</link> unless having
       rights to commit it directly to the ports tree.</para>
 
     <important>
       <para>Being a ports committer is not enough to commit to an
         arbitrary port.  Remember that ports usually have maintainers,
-        whom you should respect.</para>
+        must be respected.</para>
     </important>
 
     <para>Please make sure that the port's revision is bumped as soon
       as the vulnerability has been closed.  That is how the users who
       upgrade installed packages on a regular basis will see they need
       to run an update.  Besides, a new package will be built and
       distributed over FTP and WWW mirrors, replacing the vulnerable
-      one.  <varname>PORTREVISION</varname> should be bumped unless
+      one.  Bump <varname>PORTREVISION</varname> unless
       <varname>PORTVERSION</varname> has changed in the course of
-      correcting the vulnerability.  That is you should bump
-      <varname>PORTREVISION</varname> if you have added a patch file
-      to the port, but you should not if you have updated the port to
+      correcting the vulnerability.  That is, bump
+      <varname>PORTREVISION</varname> if adding a patch file
+      to the port, but do not bump it if updating the port to
       the latest software version and thus already touched
       <varname>PORTVERSION</varname>.  Please refer to the
       <link linkend="makefile-naming-revepoch">corresponding
         section</link> for more information.</para>
   </sect1>
 
   <sect1 xml:id="security-notify">
     <title>Keeping the Community Informed</title>
 
     <sect2 xml:id="security-notify-vuxml-db">
       <title>The VuXML Database</title>
 
       <para>A very important and urgent step to take as early after a
         security vulnerability is discovered as possible is to notify
         the community of port users about the jeopardy.  Such
-        notification serves two purposes.  First, should the danger be
+        notification serves two purposes.  First, if the danger is
         really severe it will be wise to apply an instant workaround.
-        E.g., stop the affected network service or even deinstall the
+        For example, stop the affected network service or even deinstall the
         port completely until the vulnerability is closed.  Second, a
         lot of users tend to upgrade installed packages only
         occasionally.  They will know from the notification that they
         <emphasis>must</emphasis> update the package without delay as
         soon as a corrected version is available.</para>
 
       <para>Given the huge number of ports in the tree, a security
         advisory cannot be issued on each incident without creating a
         flood and losing the attention of the audience when it comes
         to really serious matters.  Therefore security vulnerabilities
         found in ports are recorded in
         <link xlink:href="http://vuxml.freebsd.org/">the &os;
           VuXML database</link>.  The Security Officer Team members
         also monitor it for issues requiring their
         intervention.</para>
 
+      <!-- XXX: Too much "you" in there -->
       <para>If you have committer rights you can update the VuXML
         database by yourself.  So you will both help the Security
         Officer Team and deliver the crucial information to the
         community earlier.  However, if you are not a committer, or
         you believe you have found an exceptionally severe
         vulnerability please do not hesitate to contact the Security
         Officer Team directly as described on the
         <link xlink:href="http://www.freebsd.org/security/#how">&os;
           Security Information</link> page.</para>
 
       <para>The VuXML database is an <acronym>XML</acronym> document.
         Its source file <filename>vuln.xml</filename> is kept right
         inside the port <package role="port">security/vuxml</package>.
         Therefore the file's full pathname will be
         <filename>PORTSDIR/security/vuxml/vuln.xml</filename>.  Each
-        time you discover a security vulnerability in a port, please
-        add an entry for it to that file.  Until you are familiar with
-        VuXML, the best thing you can do is to find an existing entry
-        fitting your case, then copy it and use it as a
+        time a security vulnerability is discovered in a port, please
+        add an entry for it to that file.  Until familiar with
+        VuXML, the best thing to do is to find an existing entry
+        fitting the case at hand, then copy it and use it as a
         template.</para>
     </sect2>
 
     <sect2 xml:id="security-notify-vuxml-intro">
       <title>A Short Introduction to VuXML</title>
 
       <para>The full-blown <acronym>XML</acronym> format is complex,
         and far beyond the scope of this book.  However, to gain basic
-        insight on the structure of a VuXML entry you need only the
-        notion of tags.  XML tag names are enclosed in angle brackets.
+        insight on the structure of a VuXML entry only the notion of
+        tags is needed.  XML tag names are enclosed in angle brackets.
         Each opening &lt;tag&gt; must have a matching closing
         &lt;/tag&gt;.  Tags may be nested.  If nesting, the inner tags
         must be closed before the outer ones.  There is a hierarchy of
-        tags, i.e., more complex rules of nesting them.  This is
+        tags, that is, more complex rules of nesting them.  This is
         similar to HTML.  The major difference is that XML is
-        e<emphasis>X</emphasis>tensible, i.e., based on defining
+        e<emphasis>X</emphasis>tensible, that is, based on defining
         custom tags.  Due to its intrinsic structure XML puts
         otherwise amorphous data into shape.  VuXML is particularly
         tailored to mark up descriptions of security
         vulnerabilities.</para>
 
       <para>Now consider a realistic VuXML entry:</para>
 
       <programlisting>&lt;vuln vid="f4bc80f4-da62-11d8-90ea-0004ac98a7b9"&gt; <co xml:id="co-vx-vid"/>
<chapter xmlns="http://docbook.org/ns/docbook"
   &lt;dates&gt;
     &lt;discovery&gt;2010-05-25&lt;/discovery&gt; <co xml:id="co-vx-dsc"/>
     &lt;entry&gt;2010-07-13&lt;/entry&gt; <co xml:id="co-vx-ent"/>
     &lt;modified&gt;2010-09-17&lt;/modified&gt; <co xml:id="co-vx-mod"/>
   &lt;/dates&gt;
 &lt;/vuln&gt;</programlisting>
 
       <para>The tag names are supposed to be self-explanatory so we
-        shall take a closer look only at fields you will need to fill
-        in by yourself:</para>
+        shall take a closer look only at fields which needs to be fill
+        in:</para>
 
       <calloutlist>
         <callout arearefs="co-vx-vid">
           <para>This is the top-level tag of a VuXML entry.  It has a
             mandatory attribute, <literal>vid</literal>, specifying a
             universally unique identifier (UUID) for this entry (in
-            quotes).  You should generate a UUID for each new VuXML
+            quotes).  Generate a UUID for each new VuXML
             entry (and do not forget to substitute it for the template
-            UUID unless you are writing the entry from scratch).  You
-            can use &man.uuidgen.1; to generate a VuXML UUID.</para>
+            UUID unless writing the entry from scratch).
+            use &man.uuidgen.1; to generate a VuXML UUID.</para>
         </callout>
 
         <callout arearefs="co-vx-top">
           <para>This is a one-line description of the issue
             found.</para>
         </callout>
 
         <callout arearefs="co-vx-nam">
           <para>The names of packages affected are listed there.
             Multiple names can be given since several packages may be
             based on a single master port or software product.  This
             may include stable and development branches, localized
             versions, and slave ports featuring different choices of
             important build-time configuration options.</para>
 
           <important>
-            <para>It is your responsibility to find all such related
+            <para>It is the submitter's responsibility to find all such related
               packages when writing a VuXML entry.  Keep in mind that
-              <literal>make search name=foo</literal> is your friend.
-              The primary points to look for are as follows:</para>
+              <literal>make search name=foo</literal> is helpful.
+              The primary points to look for are:</para>
 
             <itemizedlist>
               <listitem>
                 <para>the <filename>foo-devel</filename> variant for a
                   <filename>foo</filename> port;</para>
               </listitem>
 
               <listitem>
&lt;/vuln&gt;</programlisting>
 
         <callout arearefs="co-vx-rng">
           <para>Affected versions of the package(s) are specified
             there as one or more ranges using a combination of
             <literal>&lt;lt&gt;</literal>,
             <literal>&lt;le&gt;</literal>,
             <literal>&lt;eq&gt;</literal>,
             <literal>&lt;ge&gt;</literal>, and
-            <literal>&lt;gt&gt;</literal> elements.  The version
-            ranges given should not overlap.</para>
+            <literal>&lt;gt&gt;</literal> elements.  Check the version
+            ranges given do not overlap.</para>
 
           <para>In a range specification, <literal>*</literal>
             (asterisk) denotes the smallest version number.  In
             particular, <literal>2.*</literal> is less than
             <literal>2.a</literal>.  Therefore an asterisk may be used
             for a range to match all possible
             <literal>alpha</literal>, <literal>beta</literal>, and
             <literal>RC</literal> versions.  For instance,
<para>Several related package groups (essentially, ports)
             section.  This can be used if several software products
             (say FooBar, FreeBar and OpenBar) grow from the same code
             base and still share its bugs and vulnerabilities.  Note
             the difference from listing multiple names within a single
             &lt;package&gt; section.</para>
         </callout>
 
         <callout arearefs="co-vx-epo">
-          <para>The version ranges should allow for
+          <para>The version ranges have to allow for
             <varname>PORTEPOCH</varname> and
             <varname>PORTREVISION</varname> if applicable.  Please
             remember that according to the collation rules, a version
             with a non-zero <varname>PORTEPOCH</varname> is greater
             than any version without <varname>PORTEPOCH</varname>,
-            e.g., <literal>3.0,1</literal> is greater than
+            for example, <literal>3.0,1</literal> is greater than
             <literal>3.1</literal> or even than
             <literal>8.9</literal>.</para>
         </callout>
 
         <callout arearefs="co-vx-bdy">
           <para>This is a summary of the issue.  XHTML is used in this
             field.  At least enclosing <literal>&lt;p&gt;</literal>
-            and <literal>&lt;/p&gt;</literal> should appear.  More
+            and <literal>&lt;/p&gt;</literal> has to appear.  More
             complex mark-up may be used, but only for the sake of
             accuracy and clarity: No eye candy please.</para>
         </callout>
 
         <callout arearefs="co-vx-ref">
           <para>This section contains references to relevant
             documents.  As many references as apply are
             encouraged.</para>
         </callout>
 
         <callout arearefs="co-vx-fsa">
           <para>This is a <link
               xlink:href="http://www.freebsd.org/security/#adv">&os;
               security advisory</link>.</para>
         </callout>
 
         <callout arearefs="co-vx-fpr">
           <para>This is a <link
-              xlink:href="http://www.freebsd.org/support.html#gnats">&os;
+              xlink:href="http://www.freebsd.org/support.html">&os;
               problem report</link>.</para>
         </callout>
 
         <callout arearefs="co-vx-cve">
           <para>This is a
             <link xlink:href="http://www.cve.mitre.org/">MITRE
               CVE</link> identifier.</para>
         </callout>
&lt;/vuln&gt;</programlisting>
 
         <callout arearefs="co-vx-mls">
           <para>This is a URL to an archived posting in a mailing
             list.  The attribute <literal>msgid</literal> is optional
             and may specify the message ID of the posting.</para>
         </callout>
 
         <callout arearefs="co-vx-url">
-          <para>This is a generic URL.  It should be used only if none
+          <para>This is a generic URL.  Only it if none
             of the other reference categories apply.</para>
         </callout>
 
         <callout arearefs="co-vx-dsc">
           <para>This is the date when the issue was disclosed
             (<replaceable>YYYY-MM-DD</replaceable>).</para>
         </callout>
 
         <callout arearefs="co-vx-ent">
           <para>This is the date when the entry was added
             (<replaceable>YYYY-MM-DD</replaceable>).</para>
         </callout>
 
         <callout arearefs="co-vx-mod">
           <para>This is the date when any information in the entry was
             last modified (<replaceable>YYYY-MM-DD</replaceable>).
-            New entries must not include this field.  It should be
-            added upon editing an existing entry.</para>
+            New entries must not include this field.  Add it when
+            editing an existing entry.</para>
         </callout>
       </calloutlist>
     </sect2>
 
     <sect2 xml:id="security-notify-vuxml-testing">
-      <title>Testing Your Changes to the VuXML Database</title>
+      <title>Testing Changes to the VuXML Database</title>
 
-      <para>Assume you just wrote or filled in an entry for a
+      <para>Assume a new entry for a
         vulnerability in the package <literal>clamav</literal> that
         has been fixed in version <literal>0.65_7</literal>.</para>
 
-      <para>As a prerequisite, you need to
+      <para>As a prerequisite,
         <emphasis>install</emphasis> fresh versions of the ports
         <package role="port">ports-mgmt/portaudit</package>,
         <package role="port">ports-mgmt/portaudit-db</package>, and
         <package role="port">security/vuxml</package>.</para>
 
       <note>
-        <para>To run <command>packaudit</command> you must have
+        <para>The user running <command>packaudit</command> must have
           permission to write to its <filename>DATABASEDIR</filename>,
           typically <filename>/var/db/portaudit</filename>.</para>
 
-        <para>To use a different directory set the
-          <filename>DATABASEDIR</filename> environment variable to a
+        <para>To use a different directory, set the
+          <varname>DATABASEDIR</varname> environment variable to a
           different location.</para>
 
-        <para>If you are working in a directory other than
-          <filename>${PORTSDIR}/security/vuxml</filename> set the
-          <filename>VUXMLDIR</filename> environment variable to the
+        <para>If working in a directory other than
+          <filename>${PORTSDIR}/security/vuxml</filename>, set the
+          <varname>VUXMLDIR</varname> environment variable to the
           directory where <filename>vuln.xml</filename> is
           located.</para>
       </note>
 
       <para>First, check whether there already is an entry for this
         vulnerability.  If there were such an entry, it would match
         the previous version of the package,
         <literal>0.65_6</literal>:</para>
 
       <screen>&prompt.user; <userinput>packaudit</userinput>
 &prompt.user; <userinput>portaudit clamav-0.65_6</userinput></screen>
 
-      <para>If there is none found, you have the green light to add a
+      <para>If there is none found, add a
         new entry for this vulnerability.</para>
 
       <screen>&prompt.user; <userinput>cd ${PORTSDIR}/security/vuxml</userinput>
 &prompt.user; <userinput>make newentry</userinput></screen>
 
-      <para>When you are done verify its syntax and formatting.</para>
+      <para>Verify its syntax and formatting:</para>
 
       <screen>&prompt.user; <userinput>make validate</userinput></screen>
 
       <note>
-        <para>You will need at least one of the following packages
+        <para>At least one of these packages needs to be
           installed: <package role="port">textproc/libxml2</package>,
           <package role="port">textproc/jade</package>.</para>
       </note>
 
       <para>Now rebuild the <command>portaudit</command> database from
         the VuXML file:</para>
 
       <screen>&prompt.user; <userinput>packaudit</userinput></screen>
 
       <para>To verify that the <literal>&lt;affected&gt;</literal>
-        section of your entry will match correct package(s), issue the
-        following command:</para>
+        section of the entry will match correct package(s), issue this
+        command:</para>
 
       <screen>&prompt.user; <userinput>portaudit -f /usr/ports/INDEX -r <replaceable>uuid</replaceable></userinput></screen>
 
       <note>
         <para>Please refer to &man.portaudit.1; for better
           understanding of the command syntax.</para>
       </note>
 
-      <para>Make sure that your entry produces no spurious matches in
+      <para>Make sure that the entry produces no spurious matches in
         the output.</para>
 
       <para>Now check whether the right package versions are matched
-        by your entry:</para>
+        by the entry:</para>
 
       <screen>&prompt.user; <userinput>portaudit clamav-0.65_6 clamav-0.65_7</userinput>
 Affected package: clamav-0.65_6 (matched by clamav&lt;0.65_7)
 Type of problem: clamav remote denial-of-service.
 Reference: &lt;http://www.freebsd.org/ports/portaudit/74a9541d-5d6c-11d8-80e3-0020ed76ef5a.html&gt;
 
 1 problem(s) found.</screen>
 
-      <para>The former version should match while the latter one
-        should not.</para>
+      <para>The former version matches while the latter one
+        does not.</para>
 
       <para>Finally, verify whether the web page generated from the
         VuXML database looks like expected:</para>
 
       <screen>&prompt.user; <userinput>mkdir -p ~/public_html/portaudit</userinput>
 &prompt.user; <userinput>packaudit</userinput>
 &prompt.user; <userinput>lynx ~/public_html/portaudit/74a9541d-5d6c-11d8-80e3-0020ed76ef5a.html</userinput></screen>
     </sect2>
   </sect1>
 </chapter>