Re: Detect on-die temp sensor for Atom E6xx on amd64

2013-01-30 Thread Mark Kettenis
 Date: Tue, 29 Jan 2013 17:35:13 -0500
 From: Matt Dainty m...@bodgit-n-scarper.com
 
 * Christian Weisgerber na...@mips.inka.de [2013-01-24 13:03:43]:
  Matt Dainty m...@bodgit-n-scarper.com wrote:
  
   --- sys/arch/amd64/amd64/identcpu.c.orig  2013-01-14 22:23:43.0 
   +
   +++ sys/arch/amd64/amd64/identcpu.c   2013-01-14 22:33:21.0 
   +
   @@ -506,7 +506,8 @@
 if (ci-ci_feature_sefflags  SEFF0EBX_SMAP)
 replacesmap();
 }
   - if (!strncmp(mycpu_model, Intel, 5)) {
   + if (!strncmp(mycpu_model, Intel, 5) ||
   + !strncmp(mycpu_model, Genuine Intel, 13)) {
 u_int32_t cflushsz;

 CPUID(0x01, dummy, cflushsz, dummy, dummy);
   
  
  I think it's dubious that we match the CPU brand name for this at
  all.  Shouldn't this be properly handled with CPUID?
 
 Here's a slightly simpler diff that checks the vendor rather than the
 CPU brand.
 
 I'm not sure if it's safe to check CPUID regardless of vendor, plus
 there is the CLFLUSH code in that block as well, I figure that's
 confined to Intel for a reason?

Look at the equivalent i386 code.



Re: beaglebone JTAG (FT2232H)

2013-01-30 Thread Martin Pieuchot
On 27/01/13(Sun) 16:13, Raphael Graf wrote:
 The diff below makes the jtag and serial interfaces of the beaglebone 
 (FT2232H)
 work simultaneously.
 This is how the beaglebone shows up:
 
 uhub8 at uhub0 port 1 Standard Microsystems product 0x2412 rev 2.00/b.b2 
 addr 3
 uftdi0 at uhub8 port 1 configuration 1 interface 1 FTDI BeagleBone/XDS100V2 
 rev 2.00/7.00 addr 4
 ucom0 at uftdi0 portno 2
 ugen0 at uhub8 port 1 configuration 1 FTDI BeagleBone/XDS100V2 rev 
 2.00/7.00 addr 4
 
 Like this, openocd (using ugen) and cu both work.
 
 It is just assumed that interface 0 is used for jtag, not sure if this is
 always true. I'm also unsure if the diff would break other devices.
 Can someone comment on this?

Your diff looks correct and after looking at how the USB drivers are
matched it seems obvious to me that changing the configuration in this
function is not the right thing to do. 

I just rewrote your diff to keep only one (iface == NULL) check, I think
it is clearer like that. Are you ok with this version?

Tested with:
uftdi0 at uhub3 port 1 configuration 1 interface 0 FTDI USB Serial Converter 
rev 2.00/6.00 addr 2

M.

Index: uftdi.c
===
RCS file: /home/ncvs/src/sys/dev/usb/uftdi.c,v
retrieving revision 1.63
diff -u -p -r1.63 uftdi.c
--- uftdi.c 11 Sep 2012 16:04:44 -  1.63
+++ uftdi.c 30 Jan 2013 09:28:59 -
@@ -748,39 +748,29 @@ int
 uftdi_match(struct device *parent, void *match, void *aux)
 {
struct usb_attach_arg *uaa = aux;
-   usbd_status err;
-   u_int8_t nifaces;
 
-   if (usb_lookup(uftdi_devs, uaa-vendor, uaa-product) == NULL)
+   /*
+* Only attach when looping against interfaces to allow ugen(4)
+* to take over the interface 0, JTAG on USB on some models.
+*/
+   if (uaa-iface == NULL)
return (UMATCH_NONE);
 
-   /* Get the number of interfaces. */
-   if (uaa-iface != NULL) {
-   nifaces = uaa-nifaces;
-   } else {
-   err = usbd_set_config_index(uaa-device, UFTDI_CONFIG_INDEX, 1);
-   if (err)
-   return (UMATCH_NONE);
-   err = usbd_interface_count(uaa-device, nifaces);
-   if (err)
-   return (UMATCH_NONE);
-   usbd_set_config_index(uaa-device, USB_UNCONFIG_INDEX, 1);
-   }
+   if (usb_lookup(uftdi_devs, uaa-vendor, uaa-product) == NULL)
+   return (UMATCH_NONE);
 
/* JTAG on USB interface 0 */
if (uaa-vendor == USB_VENDOR_FTDI 
-   uaa-product == USB_PRODUCT_FTDI_OPENRD 
+   (uaa-product == USB_PRODUCT_FTDI_OPENRD ||
+   uaa-product == USB_PRODUCT_FTDI_SERIAL_2232C) 
uaa-ifaceno == 0)
return (UMATCH_NONE);
 
-   if (nifaces = 1)
+   if (uaa-nifaces = 1)
return (UMATCH_VENDOR_PRODUCT);
 
/* Dual UART chip */
-   if (uaa-iface != NULL)
-   return (UMATCH_VENDOR_IFACESUBCLASS);
-   else
-   return (UMATCH_NONE);
+   return (UMATCH_VENDOR_IFACESUBCLASS);
 }
 
 void



Re: system freeze with DWL-G520 and possible fix

2013-01-30 Thread Dinar Talypov
Any comments on this?


2013/1/16 Dinar Talypov t.dina...@gmail.com:
 Hi,

 My D-link DWL-G520 card attaches on ath(4):

 ath0 at pci0 dev 9 function 0 Atheros AR5212 rev 0x01: irq 11
 ath0: AR2414 7.9 phy 4.5 rf2413 5.6, FCC2A*, address 00:17:9a:09:f4:5a

 On ifconfig ath0 down  ifconfig ath0 up I've got system freeze.

 Googleing showed that system can freeze on register read or write
 while AR5212 chip in full sleep mode. And it is not possible to wake it up.
 This implies only for some AR5212 chips.

 In linux this is solved by making warm reset, instead
 of putting it in full sleep mode.
 The diff below does the same thing.
 What do you think about it? Or warm_reset function
 must be called only for particular chips?

 Index: ar5212.c
 ===
 RCS file: /cvs/src/sys/dev/ic/ar5212.c,v
 retrieving revision 1.52
 diff -u -r1.52 ar5212.c
 --- ar5212.c14 Oct 2011 17:08:09 -  1.52
 +++ ar5212.c16 Jan 2013 16:58:33 -
 @@ -30,6 +30,7 @@
  u_int16_t   ar5k_ar5212_radio_revision(struct ath_hal *, HAL_CHIP);
  voidar5k_ar5212_fill(struct ath_hal *);
  HAL_BOOLar5k_ar5212_txpower(struct ath_hal *, HAL_CHANNEL *, u_int);
 +HAL_BOOLar5k_ar5212_warm_reset(struct ath_hal *);

  /*
   * Initial register setting for the AR5212
 @@ -2420,6 +2421,44 @@
  }

  /*
 + * Put MAC and Baseband on warm reset and keep that state
 + * (don't clean sleep control register). After this MAC
 + * and Baseband are disabled and a full reset is needed
 + * to come back. This way we save as much power as possible
 + * without putting the card on full sleep.
 + */
 +
 +HAL_BOOL
 +ar5k_ar5212_warm_reset(struct ath_hal *hal)
 +{
 +   u_int32_t flags;
 +
 +   flags = AR5K_AR5212_RC_PCU | AR5K_AR5212_RC_BB;
 +   if (hal-ah_pci_express == AH_FALSE)
 +   flags |= AR5K_AR5212_RC_PCI;
 +
 +   if (ar5k_ar5212_nic_reset(hal, flags) == AH_FALSE) {
 +   AR5K_PRINT(failed to reset the AR5212 + PCI chipset\n);
 +   return (AH_FALSE);
 +   }
 +
 +   /* ...wakeup */
 +   if (ar5k_ar5212_set_power(hal,
 +   HAL_PM_AWAKE, AH_TRUE, 0) == AH_FALSE) {
 +   AR5K_PRINT(failed to resume the AR5212 (again)\n);
 +   return (AH_FALSE);
 +   }
 +
 +   /* Put chipset on warm reset... */
 +   if (ar5k_ar5212_nic_reset(hal, 0) == AH_FALSE) {
 +   AR5K_PRINT(failed to warm reset the AR5212\n);
 +   return (AH_FALSE);
 +   }
 +
 +   return (AH_TRUE);
 +}
 +
 +/*
   * Power management functions
   */

 @@ -2445,10 +2484,8 @@
 break;

 case HAL_PM_FULL_SLEEP:
 -   if (set_chip == AH_TRUE) {
 -   AR5K_REG_WRITE(AR5K_AR5212_SCR,
 -   AR5K_AR5212_SCR_SLE_SLP);
 -   }
 +   if (set_chip == AH_TRUE)
 +   ar5k_ar5212_warm_reset(hal);
 staid |= AR5K_AR5212_STA_ID1_PWR_SV;
 break;



 --
 Dinar Talypov t.dina...@gmail.com



Re: Detect on-die temp sensor for Atom E6xx on amd64

2013-01-30 Thread Matt Dainty
* Mark Kettenis mark.kette...@xs4all.nl [2013-01-30 03:49:45]:
  Date: Tue, 29 Jan 2013 17:35:13 -0500
  From: Matt Dainty m...@bodgit-n-scarper.com
  
  * Christian Weisgerber na...@mips.inka.de [2013-01-24 13:03:43]:
   Matt Dainty m...@bodgit-n-scarper.com wrote:
   
--- sys/arch/amd64/amd64/identcpu.c.orig2013-01-14 
22:23:43.0 +
+++ sys/arch/amd64/amd64/identcpu.c 2013-01-14 22:33:21.0 
+
@@ -506,7 +506,8 @@
if (ci-ci_feature_sefflags  SEFF0EBX_SMAP)
replacesmap();
}
-   if (!strncmp(mycpu_model, Intel, 5)) {
+   if (!strncmp(mycpu_model, Intel, 5) ||
+   !strncmp(mycpu_model, Genuine Intel, 13)) {
u_int32_t cflushsz;
 
CPUID(0x01, dummy, cflushsz, dummy, dummy);

   
   I think it's dubious that we match the CPU brand name for this at
   all.  Shouldn't this be properly handled with CPUID?
  
  Here's a slightly simpler diff that checks the vendor rather than the
  CPU brand.
  
  I'm not sure if it's safe to check CPUID regardless of vendor, plus
  there is the CLFLUSH code in that block as well, I figure that's
  confined to Intel for a reason?
 
 Look at the equivalent i386 code.

It looks like the i386 code ultimately does the same thing, looking
through i386/machdep.c, the CPUID is only checked in
intel686_cpusensors_setup() which is traced back to the big
i386_cpuid_cpus[] struct and intel686_cpu_setup()/intel686_p4_cpu_setup()
which to my eyes only gets called for Intel CPUs.

Matt



Re: Rapoo V7 Keyboard Driver

2013-01-30 Thread Daniel Bolgheroni
On Mon, Jan 28, 2013 at 03:01:08PM -0800, Mike Larkin wrote:
 
 The diff above might work but when I tried something akin to that last year
 when implementing support for the Monoprice keyboard (similar mechanical
 'gaming' style keyboard), the boot protocol only allowed one key pressed at 
 a time. That meant no Shift/Ctrl/Alt which made things somewhat difficult.

As a workaround, it works OK with boot protocol, despite the fact the
mouse wheel gone.

BTW, what's the correct approach here? This keyboard is a 3-in-1, and 2
of them attach as ukbd and one as uhid. Is it work to attach the uhid
one as ukbd?

Thank you.



Re: vfs_syscall: doreadlinkat()

2013-01-30 Thread Matthew Dempsky
Committed, thanks!