lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 30 Nov 2009 09:10:07 +0100
From:	Marc Zyngier <maz@...terjones.org>
To:	Eric Miao <eric.y.miao@...il.com>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	Dominik Brodowski <linux@...inikbrodowski.net>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Russell King - ARM Linux <linux@....linux.org.uk>
Subject: Re: linux-next: manual merge of the pcmcia tree with the pxa tree

On Mon, 30 Nov 2009 11:17:08 +0800
Eric Miao <eric.y.miao@...il.com> wrote:

Hi Eric,

> Could you take a look into this, I wonder you may need to rebase
> against Russell's PCMCIA generalization stuffs. Let me know if you
> want me to drop this patch.

Patch looks good. I'm more worried about creating dependencies between
trees:

- Stephen fix depends on Russell's changes, which are in Dominik's tree,
- My patch depends on Zeus support, which is in your tree,
- Rebasing Zeus PCMCIA support against Dominik's tree is just another
  dependency between the two trees.

Should we drop my PCMCIA changes until both Russell's changes and main
Zeus support are merged?

I'm opened to any suggestion.

	M.

> 
> On Mon, Nov 30, 2009 at 10:16 AM, Stephen Rothwell
> <sfr@...b.auug.org.au> wrote:
> > Hi Dominik,
> >
> > Today's linux-next merge of the pcmcia tree got a conflict in
> > drivers/pcmcia/pxa2xx_viper.c between commit
> > c9b74a4489db7e6fe03fbee11f406b9641baae55 ("[ARM] pxa/zeus: make
> > Viper pcmcia support more generic to support Zeus") from the pxa
> > tree and commit 66024db57d5b9011e274b314affad68f370c0d6f ("PCMCIA:
> > stop duplicating pci_irq in soc_pcmcia_socket") from the pcmcia
> > tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary.
> > --
> > Cheers,
> > Stephen Rothwell                    sfr@...b.auug.org.au
> >
> > diff --cc drivers/pcmcia/pxa2xx_viper.c
> > index 7a16ae9,27be2e1..0000000
> > --- a/drivers/pcmcia/pxa2xx_viper.c
> > +++ b/drivers/pcmcia/pxa2xx_viper.c
> > @@@ -30,35 -32,23 +30,35 @@@
> >  #include "soc_common.h"
> >  #include "pxa2xx_base.h"
> >
> >  +static struct platform_device *arcom_pcmcia_dev;
> >  +
> >  static struct pcmcia_irqs irqs[] = {
> >  -      { 0, gpio_to_irq(VIPER_CF_CD_GPIO),  "PCMCIA_CD" }
> >  +      {
> >  +              .sock   = 0,
> >  +              .str    = "PCMCIA_CD",
> >  +      },
> >  };
> >
> >  +static inline struct arcom_pcmcia_pdata *viper_get_pdata(void)
> >  +{
> >  +      return arcom_pcmcia_dev->dev.platform_data;
> >  +}
> >  +
> >  static int viper_pcmcia_hw_init(struct soc_pcmcia_socket *skt)
> >  {
> >  +      struct arcom_pcmcia_pdata *pdata = viper_get_pdata();
> >        unsigned long flags;
> >
> > -       skt->irq = gpio_to_irq(pdata->rdy_gpio);
> >  -      skt->socket.pci_irq = gpio_to_irq(VIPER_CF_RDY_GPIO);
> > ++      skt->socket.pci_irq = gpio_to_irq(pdata->rdy_gpio);
> >  +      irqs[0].irq = gpio_to_irq(pdata->cd_gpio);
> >
> >  -      if (gpio_request(VIPER_CF_CD_GPIO, "CF detect"))
> >  +      if (gpio_request(pdata->cd_gpio, "CF detect"))
> >                goto err_request_cd;
> >
> >  -      if (gpio_request(VIPER_CF_RDY_GPIO, "CF ready"))
> >  +      if (gpio_request(pdata->rdy_gpio, "CF ready"))
> >                goto err_request_rdy;
> >
> >  -      if (gpio_request(VIPER_CF_POWER_GPIO, "CF power"))
> >  +      if (gpio_request(pdata->pwr_gpio, "CF power"))
> >                goto err_request_pwr;
> >
> >        local_irq_save(flags);
> >
> 


-- 
And if you don't know where you're going, any road will take you
there...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ